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I.  INTRODUCTION 

A.         GENERAL 

There  has  been  continuous  progress  in  the  development  of  computers  over  the 
past  four  decades.  The  results  are  more  impressive  by  any  measure  in  the  state  of 
hardware  than  in  the  state  of  software.  From  the  beginning  hardware  developers  have  had 
a  theoretical  basis  that  comes  from  other  sciences,  like  mathematics,  physic,  mechanics, 
etc.  Also,  the  hardware  developers  borrowed  and  applied  standard  methods  from  other 
engineering  disciplines  for  design  and  manufacturing.  In  contrast,  software  developers 
initially  relied  primarily  upon  human  imagination,  invention,  and  ingenuity.  This  lack  of 
an  engineering  approach  has  produced  legacy  software  applications  that  cannot  be 
supported  any  longer. 

As  the  science  of  software  development  slowly  evolved  into  a  distinct  engineering 
discipline,  software  engineers  established  the  processes,  the  techniques  and  the  rules  that 
govern  the  development  of  software  systems. 

The  process  to  develop  a  software  system  usually  consists  of  the  following 
phases1:  Requirements  Analysis,  Functional  Specification,  Architectural  Design, 
Implementation  and  Evolution.  In  the  nineties  the  object-oriented  methodology  has 
emerged  as  the  most  popular  method  because  it  supports  the  rule  that  can  be  described  by 
the  maxim,  "reduce,  reuse  recycle".  The  object-oriented  methodology  increases 
efficiency,  reduces  development  time  and  decreases  the  cost  of  software  products. 


1  Berzins  and  Luqi  in  their  book  "Software  Engineering  with  Abstractions"  1990  chapter  1  p  6  about  the 
Software  Development  Process 


Software  engineering  has  also  changed  the  process  of  software  evolution  and 
maintenance.  The  old  approach  "to  maintain  a  software  system  for  period  of  time  and 
then  to  replace  it  with  an  complete  new  system"  when  further  evolution  is  not  feasible  is 
not  an  efficient  solution.  It  is  too  costly  to  lose  the  assets  that  an  existent  and  working 
system  offers,  including  all  the  previous  work  that  went  into  the  requirements  analysis 
phase.  Also,  users  have  verified  the  existent  system  over  time  and  have  gained 
knowledge  about  the  system's  operations  through  years  of  maintenance  and  development. 
To  be  efficient,  the  evolution  technique '  for  an  existent  system  must  respect  that  the 
current  system  is  valuable  even  though  it  is  increasingly  difficulty  to  extend.  Therefore, 
the  new  approach  must  respect  the  assets  of  the  old  system  and  developers  should  salvage 
any  useful  parts  from  the  old  system  and  change  only  the  parts  that  must  be  changed. 

The  most  common  problem  when  re-engineering  old  systems  is  that  they  are  not 
implemented  according  to  modern,  evolvable  methods  like  the  object-oriented  design 
techniques;  however,  the  developers  can  still  use  the  requirements  specification  of  the  old 
systems  ir  the  first  phase  of  the  redesign.  So  the  designers  must  retrieve  the  requirements 
specification  from  the  old  system  and  document  them  with  object-oriented  techniques.  In 
addition,  the  most  effective  approach  to  redesign  is  to  implement  a  prototype.  In  this  way, 
the  designer  can  verify  the  correctness  of  the  requirements  specification  and  design 
through  reviews  with  the  customer. 

Current  software  engineering  techniques  are  well  supported  by  commercial-off- 
the-shelf  (COTS)  products.  Today  COTS  products  are  increasingly  important  and  highly 
economical  tools  for  organizations  to  explore  reengineering  opportunities  and  strategies. 


The  ultimate  goal  is  to  reengineer  the  old  system  using  object-oriented  techniques  that 
allows  the  concurrent  evolution  of  software  via  component-based  development. 

B.         MOTIVATION 

The  TRADOC  Analysis  Center  of  Monterey,  California  plans  to  redesign  and  re- 
implement the  Campaign  Planning  Exercises  (CAMPEX)  discussion  war  game.  The 
CAMPEX'  is  a  software  system  that  was  implemented  by  the  Air  War  College  to  provide 
students  the  opportunity  to  test  their  understanding  of  strategy,  leadership,  international 
security,  National  Security  Decision  Memorandums  (NSDM),  General  Purpose  (GP) 
forces,  unified  commands,  and  joint  fundamentals.  The  current  version  of  the  CAMPEX 
system  consists  of  two  modules,  the  "Deployment"  and  the  "Employment".  In  the 
"Deployment"  module  the  student  deploys  joint  forces  and  in  the  "Employment"  module 
he  employs  the  forces. 

The  CAMPEX  system  lifecycle  began  in  1986  and  the  current  version  (with  ID 
8.93)  was  released  in  1994.  Because  CAMPEX  is  still  used  today,  we  can  assume  that  it 
satisfies  most  requirements  of  the  Air  War  College.  Moreover,  we  can  conclude  that  the 
system  requirements  and  the  algorithms  and  other  functions  of  CAMPEX  have  been 
verified  in  practice,  because  the  CAMPEX  was  developed,  maintained,  and  used  by  Air 
War  College  personnel.  CAMPEX  was  implemented  in  the  Microsoft  Basic  Professional 
Development  System  Version  7.10,  and  the  object-oriented  techniques  were  not  used  for 


2  Air  War  College  in  the  CAMPEX  User  Manual 

3  Air  War  College  Source  Code  of  CAMPEX  last  version 


its  design.  Also,  a  serious  problem  for  further  evolution  of  CAMPEX  is  the  lack  of 
documentation  for  any  phase  of  its  development. 

An  important  constraint  that  must  be  satisfied  when  reengineering  a  current 
software  system  is  the  available  hardware.  Today  the  user  has  PC's  with  greater 
processing  power  and  data  storage  capacity  that  often  operate  on  a  high  capacity  network. 
The  reengineering  of  CAMPEX  must  account  for  this  computing  environment. 

The  final  factor  that  must  be  considered  when  reengineering  CAMPEX  is  the 
High  Level  Architecture  (HLA)  for  distributed  simulations.  The  U.S.  Department  of 
Defense  DoD)  mandates  use  of  the  HLA  in  new  simulations  and  the  retrofit  of  legacy 
simulations  by  2001. 

C.         OBJECTIVES 

This  thesis  describes  the  reengineering  of  the  CAMPEX  "Employment"  Module 
using  object-oriented  techniques  with  respect  to  the  current  user's  needs  in  combination 
with  the  current  available  hardware.  The  secondary  goal  is  preparation  for  High  Level 
Architecture  compliance  should  the  user  decide  to  distribute  CAMPEX  over  the  network. 

So  the  primary  objectives  of  my  work  were  twofold:  1)  research  in  the  area  of  the 
Distributed  Objects  Architectures  and  2)  analysis  and  redesign  of  the  CAMPEX 
"Employment"  module  with  object-oriented  techniques  and  verify  the  design  with  a  small 
prototype.  The  prototype  must  work  in  the  Microsoft  Windows  environment  and  allows 
user  to  run  some  of  the  CAMPEX  procedures  through  Internet. 


D.         THESIS  ORGANIZATION 

Chapter  II  provides: 
background  on  Distributed  Objects  Architectures, 
high  level  requirements  for  the  Distributed  Components, 
a  brief  description  of  the  partial  and  "complete"  existent  solutions  in  this  area, 
the  advantages  and  disadvantages  of  each  solution,  and 
the  common  characteristics  and  differences. 

Chapter  III  provides  the  requirements  analysis  and  functional  specification  of 
CAMPEX  Employment  that  results  from  reverse  engineering  the  current  version.  The 
requirements  analysis  and  functional  specification  are  documented  using  Unified 
Modeling  Language  (UML)  notation. 

Chapter  IV  describes  the  new  design  and  architecture  of  the  new  CAMPEX  using 
the  UML  methodology  and  notation.  The  existing  CAMPEX  algorithms  and  functions  are 
the  basis  for  the  design  of  the  object  interactions  because  the  Air  War  College  has  already 
verified  them  in  practice. 

Chapter  V  presents  the  prototype  implementation.  The  prototype  is  implemented 
with  ACCESS-2000  and  Visual  Basic.  Chapter  V  contains  the  basic  database  design, 
queries  and  forms.  Moreover,  this  chapter  offers  a  "User  Manual"  that  allows  the  user  to 
test  and  use  the  prototype  easily. 

Chapter  VI  summarizes  the  key  elements  of  the  thesis,  provides  observations 
about  the  difficulties  and  lessons  learned,  and  provides  insights  and  recommendations  for 
future  work  to  apply  the  selected  Distributed  Objects  Architecture  and  to  re-implement 
the  entire  CAMPEX. 
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II.    DISTRIBUTED  COMPONENTS  ARCHITECTURE 

A.  THE  PROBLEM  DESCRIPTION 

Even  after  many  years  the  state  of  the  art  and  science  in  software  development  is 
not  as  satisfactory  as  that  in  hardware  development.  Different  vendors  have  developed 
numerous  remarkable  applications  using  various  methods,  computer  languages,  and 
platforms.  The  exploitation  of  all  these  old  applications  in  combination  with  new 
applications  under  development  on  different  types  and  configured  machines  that  run  over 
Internet  poses  one  of  the  biggest  challenges  in  the  software  engineering  today. 

B.  REQUIREMENTS  AND  CONSTRAINTS 

This  section  addresses  the  high-level  requirements  and  constraints  to  solve  the 
problem  posed  in  the  previous  section.  First  the  object-oriented  methodology  for 
software  implementation  comprises  a  requirement  for  new  applications  and  a  constraint 
for  existing  applications.  This  general  requirement4  is  that 

•  the  applications  must  consist  of  components, 

•  the  components  should  be  characterized  by  high  cohesion  and  loose  coupling, 

•  the  components  should  be  developed  in  accordance  with  object-oriented 
principles  (encapsulation,  polymorphism  and  inheritance),  and 

•  the  components  should  communicate  through  messages. 


Reaz  Hoque  and  Tarun  Sharma  in  their  book  "WEB  Components"  1998  chapter  1  p  7  what  are  the 
Distributed  Objects 


The  second  requirement  is  to  cross  network  boundaries.  The  new  architecture 
must  allow  the  users  to  utilize  applications  that  consist  of  components  that  can  be 
distributed  on  different  machines  on  WANs  or  LANs.  This  requirement  demands  that  the 
application  access  the  network  in  standard  ways  and  expand  its  address  space  to  the  entire 
network  effectively. 

The  third  requirement  is  that  the  components  should  be  programming  language 
independent.  That  is,  components  that  are  developed  in  different  programming  languages 
be  able  to  interoperate  in  a  distributed  system.  At  the  same  time  the  user  must  be  able  to 
choose  a  unique  tool  for  the  creation  and  the  integration  of  these  heterogeneous 
components. 

The  fourth  requirement  is  to  cross  the  platform  boundaries.  The  new  architecture 
must  allow  the  old  legacy  applications  as  well  as  the  new  ones  to  run  on  machines  of 
different  type  or  configuration.  In  other  words,  machines  and  their  operating  system 
should  not  block  communication  among  the  components  of  the  distributed  application. 

The  fifth  requirement  is  to  satisfy  the  "reduce,  reuse,  recycle"  dictum.  This 
requires  that  the  application  be  reusable  as  a  whole  or  in  parts  (patterns,  components  or 
objects).  The  application  must  be  designed  so  that  it  can  be  deployed  in  an  environment 
with  diminished  resources  and  function  in  a  reduced,  but  useful,  capacity.  Finally,  it 
must  provide  components  and  design  features  that  can  be  recycled  for  the  production  of 
new  applications. 

The  sixth  and  last  requirement  is  that  the  application  must  offer  a  satisfactory 
level  of  performance  and  reliability.  This  constraint  follows  directly  from  the  maxim  to 
"reduce".    "Reduce"   excludes   solutions   that   increase   the   implementation   time    and 
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complexity.  This  excludes  many  popular  solutions  that  are  used  today.  Examples  include 
the  4GL  languages  with  fat  clients,  the  development  of  low  level  drivers  and  new 
network  protocols  for  the  crossing  of  network  boundaries,  and  the  use  of  different  tools 
with  each  programming  language  for  breaching  the  programming  language  barriers. 
A  final  constraint  is  that  the  new  system  should  demand  no  new  resources. 

C.         DISTRIBUTED  COMPONENTS  SERVICES 

Today  many  vendors  have  software  development  solutions  that  seem  to  satisfy  all 
these  requirements.  These  solutions  are  variants  of  the  Distributed  Components  Based 
Architecture.  All  the  vendors  contend  that  they  have  realized  the  early  dream  of  the 
software  community  for  distributed  computing  that  properly  uses  all  the  capabilities  of 
the  current  hardware. 

Distributed  architectures  must  offer  the  following  services5: 

•  naming  service  to  provide  a  mechanism  for  locating  distributed  components  in 
a  system, 

•  monitor  service  to  watch  the  whole  system  for  correctness  and  alert  if 
something  wrong  happens  to  an  operator, 

•  listening  service  to  ensure  that  users  of  the  distributed  components  have  the 
appropriate  privileges, 

•  persistence  mechanism  to  uniformly  save,  update,  and  restore  an  object's  state 
using  a  persistent  data  store, 


SUN  Microsystems  in  JINI  Architecture  Specification  version  1.0.1  1999  about  Distributed  Components 
Services 


•  transaction  support  mechanism  to  ensure  that  a  transaction  is  completed  or 
aborted  in  its  entirety  whenever  work  is  performed.  (Typically  a  transaction 
defines  an  atomic  unit  of  work  in  an  enterprise  system.  A  distributed 
transaction  is  a  single  unit  of  work  that  spans  multiple  computers.) 

•  security  mechanisms  to  ensure  that  communication  from  authorized  users  to  a 
distributed  object  is  secure, 

•  messaging  support  to  provide  an  asynchronous  programming  model,  as 
opposed  to  the  typical  request-reply  model.  (There  are  many  types  of 
applications  that  require  messaging.  An  example  is  an  application  in  which  the 
client  and  server  are  required  to  run  in  different  times.) 

•  distributed  services  to  automatically  deallocate  distributed  objects  when  they 
are  no  longer  being  used  by  their  clients,  and 

•  resource  management  to  manage  distributed  objects  in  such  a  way  as  to 
maximize  scalability  and  support  a  large  number  of  clients  interacting  with  a 
large  number  of  distributed  objects  in  short  period  of  time. 

D.         EXISTING  PARTIAL  SOLUTIONS 

Today  there  are  many  suggestions  from  different  vendors.  Some  of  these 
suggestions  tackle  the  problem  of  the  distributed  computing  by  trying  to  satisfy  all  the 
requirements  and  others  by  trying  primarily  to  satisfy  an  individual  requirement. 

The  following  techniques  suggest  solutions  for  various  requirements  of  the  distributed 

computing  problem: 
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The  Remote  Procedure  Call  Mechanism  satisfies  the  requirement  to  cross  network 
boundaries.  It  is  probably  the  most  popular  technique  for  crossing  network  barriers.  At 
first  sight  it  seems  well  suitable  for  distributed  computing  since  it  allows  one 
application  to  make  functions  calls  through  the  network.  However,  if  we  examine 
RPC  deeper  we  find  that  RPC  does  not  allow  the  objects  to  change  state.  Adding  this 
capability  has  a  very  large  performance  cost. 

Sockets  mechanisms7  are  another  way  to  cross  network  barriers.  This  solution  has 
many  advantages,  but  it  usually  demands  low-level  network  programming.  To  be 
useful  for  distributed  computing  architectures  this  solution  should  offer  network 
interfaces  that  hide  all  the  unnecessary  low  level  networking  details. 

Q 

Interpreted  Languages  can  solve  the  problem  of  the  crossing  operating  system  (OS) 
boundaries.  Since  this  kind  of  languages  is  not  compiled  to  a  specific  binary  format, 
they  can  be  reused  and  run  in  source  code  format  on  multiple  machines.  The  drawback 
of  this  solution  is  the  lack  of  speed  because  interpreted  code  is  typically  hundreds  of 
times  slower  than  the  compiled  code;  also,  the  interpeter  may  not  exists  for  some 
platforms. 

Binary  Compatibility  Layers  can  be  used  to  cross  OS  barriers.  This  solution  provides  a 
layer  of  code  on  top  of  the  OS  that  runs  binary  files  compiled  for  a  different  OS.  This 
solution  is  feasible  if  binary  compatibility  layers  exist  for  all  the  OS's.  One  problem 
with  this  solution  is  that  it  demands  a  lot  of  work  from  programmers.  Another 


6  Gopalan  Suresh  Raj  in  his  book  "A  Detailed  Comparison  of  CORBA,  DCOM  and  JAVA/JINI 

7  Reaz  Hoque  and  Tarun  Sharma  in  their  book  "WEB  Components"  1998  chapter  1  p.  14  what  are  the 
Distributed  Objects 
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problem  is  that  most  applications  use  more  than  one  OS  layer,  so  the  OS  vendor  must 
construct  a  new  binary  compatibility  layer  every  time  another  OS  layer  is  used. 
Language  Binding  can  cross  language  barriers.  The  biggest  weakness  of  this 
technique  is  that  users  must  learn  how  the  solution  works  in  different  programming 
environment.  Consequently,  it  is  not  standard  and  can  delay  the  implementation 
process. 

Another  way  to  cross  language  barriers  is  a  development  environment  that  can 
compile  to  multiple  target  platforms.  But  this  solution  has  a  big  drawback  too.  It 
demands  a  binary  distribution. 

E.         EXISTING  COMPLETE  SOLUTIONS 

The  previous  section  discussed  the  most  common  partial  solutions  for  distributed 
computing  and  emphasized  their  drawbacks.  This  section  describes  standard  complete 
solutions. 

The  Distributed  Component  Object  Model  (DCOM)  is  Microsoft's  solution  for 
distributed  computing.  DCOM  treats  the  problem  of  the  distributed  components  as  two 
different  subproblems.  The  first  subproblem9  is  the  component  architecture  that  describes 
component  packaging  and  cross  language  interoperability.  The  second  sub-problem  is 
communication  among  components  over  the  network  and  support  for  remote  method 
invocation. 


Reaz  Hoque  and  Tarun  Sharma  in  their  book  "WEB  Components"  1998  chapter  1  p  15  what  are  the 
Distributed  Objects 

Software  Engineering  Institute  DCOM  Architecture  Overview,  10  Jan  97,  p. 2  by  Ed  Morris  and  Emil 
Litvak 
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COM,  an  ancestor  of  the  DCOM  and  now  a  part  of  DCOM,  allows  inter-process 
communication.  COM  supports  interoperability  and  reusability  of  distributed  objects  by 
allowing  developers  to  build  systems  by  assembling  reusable  components  from  different 
vendors.  By  applying  COM  to  build  systems  from  preexisting  components  developers 
hope  to  reap  benefits  like  maintainability  and  adaptability. 

COM  defines  an  application-programming  interface  (API)  for  creating 
components  to  use  in  custom  applications  and  to  allow  components  to  interact.  However, 
the  interacting  components  must  adhere  to  a  binary  structure  specified  by  Microsoft.  As 
long  as  they  adhere  to  this  binary  structure,  components  written  in  different  languages 
can  interoperate. 

The  DCOM  extends  the  COM  by  allowing  network-based  component  interaction. 
While  COM  processes  can  run  on  the  same  machine  in  different  address  spaces,  the 
DCOM  extension  allows  processes  to  be  spread  across  a  network.  With  DCOM, 
components  operating  on  a  variety  of  platforms  can  interact  as  long  as  DCOM  is 
available  within  the  environment.  COM  and  DCOM  represent  "low-level"  technology 
that  allows  components  to  interact.  Microsoft  provides  two  higher-level  application 
services,  OLE  and  ActiveX,  which  are  built  on  top  of  COM  and  DCOM.  OLE  provides 
services  such  as  object  "linking"  and  "embedding"  that  are  used  in  the  creation  of 
compound  documents  (documents  generated  from  multiple  tool  sources).  ActiveX  allows 
components  to  be  embedded  in  Web  pages. 

COM  is  a  binary  compatibility  specification  and  associated  implementation  that 
allows  clients  to  invoke  services  provided  by  COM-compliant  components  (COM 
objects).  As  shown  in  Figure  1  services  implemented  by  COM  objects  are  exposed 
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through  a  set  of  interfaces  that  represent  the  only  point  of  contact  between  the  clients  and 
the  object. 
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Figure  1.  Client  Using  COM  Object  Through  an  Interface  Pointer  (Source: 
Software  Engineering  Institute  DCOM  Architecture  Overview,  10  Jan  97,  p.2.) 


COM  defines  a  binary  structure  for  the  interface  between  the  client  and  the  object. 
This  binary  structure  provides  the  basis  for  interoperability  among  software  components 
written  in  arbitrary  languages.  As  long  as  a  compiler  can  reduce  language  structures 
down  to  this  binary  representation,  the  implementation  language  of  the  client  is 
independent  from  the  run-time  binary  representation  of  the  object.  Thus,  COM  objects 
and  clients  can  be  coded  in  any  language  that  supports  Microsoft's  COM  binary  structure. 

An  interface  provides  a  collection  of  related  methods.  COM  objects  and  interfaces 
are  specified  using  Microsoft  Interface  Definition  Language  (DDL),  an  extension  of  the 
DCE  Interface  Definition  Language  standard.  To  avoid  name  collisions,  each  object  and 
interface  must  have  a  unique  identifier. 

Every  COM  object  runs  within  of  a  server.  A  single  server  can  support  multiple 
COM  objects.  There  are  three  ways  in  which  a  client  can  access  COM  objects  provided 
by  a  server: 
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Figure  2.  Three  Methods  for  Accessing  COM  Objects  (Source:  Software 
Engineering  Institute  DCOM  Architecture  Overview,  10  Jan  97,  p.4.) 


•  In-process  server:  The  client  can  link  to  a  library  containing  the  server 
directly.  The  client  and  server  execute  in  the  same  process.  Communication  is 
accomplished  through  function  calls. 

•  Local  Object  Proxy:  The  client  can  access  a  server  running  in  a  different 
process  yet  on  the  same  machine  through  an  inter-process  communication 
mechanism.  This  mechanism  is  actually  a  lightweight  Remote  Procedure  Call 
(RPC). 
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•     Remote  Object  Proxy:  The  client  can  access  a  remote  server  running  on 

another  machine.  The  network  communication  between  client  and  server  is 

accomplished  through  DCE  RPC.  The  mechanism  supporting  access  to  remote 

servers  is  called  DCOM. 

If  the  client  and  the  server  are  in  the  same  process,  the  sharing  of  data  between 

them  is  simple.  However,  when  the  server  process  is  separate  from  the  client  process,  as 

in  a  local  server  or  remote  server,  COM  must  format  and  bundle  the  data  in  order  to  share 

it.  This  process  of  preparing  the  data  is  called  marshalling.  Marshalling  is  accomplished 

through    a    "proxy"    object    and    a    "stub"    object    that    handles    the    cross-process 

communication  details  for  any  particular  interface.  COM  creates  the  "stub"  in  the  object's 

server  process  and  has  the  stub  manage  to  the  real  interface  pointer.  Then  COM  creates 

the  "proxy"  in  the  client's  process,  and  connects  it  to  the  stub.  Then  the  proxy  supplies  the 

interface  pointer  to  the  client. 

The  client  calls  the  interfaces  of  the  server  through  the  proxy,  which  marshals  the 
parameters  and  passes  them  to  the  server  stub.  The  stub  unmarshals  the  parameters  and 
makes  the  actual  call  inside  the  server  object.  When  the  call  is  completed,  the  stub 
marshals  return  values  and  passes  them  to  the  proxy,  which  in  turn  returns  them  to  the 
client.  The  same  proxy/stub  mechanism  is  used  when  the  client  and  server  are  on 
different  machines.  However,  the  internal  implementation  of  marshalling  and 
unmarshalling  differs  depending  on  whether  the  client  and  server  operate  on  the  same 
machine  (COM)  or  on  different  machines  (DCOM).  Given  an  EDL  file,  the  Microsoft 
IDL  compiler  can  create  default  proxy  and  stub  code  that  performs  all  necessary 
marshalling  and  unmarshalling. 
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Figure  3.  Cross-Process  Communication  in  COM  (Source:  Software  Engineering 
Institute  DCOM  Architecture  Overview,  10  Jan  97,  p.5.) 

All  COM  objects  are  registered  with  a  component  database.  As  shown  in  Figure 

4,  when  a  client  wishes  to  create  and  uses  a  COM  object: 

•  it  invokes  the  COM  API  to  instantiate  a  new  COM  object, 

•  COM  locates  the  object  implementation  and  initiates  a  server  process  for  the 
object, 

•  the  server  process  creates  the  object  and  returns  an  interface  pointer  at  the 
object,  and  then 

•  the  client  can  interact  with  the  newly  instantiated  COM  object  through  the 
interface  pointer. 
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figure  4.  Creating  a  COM  Object  Pointer  (Source:  Software  Engineering  Institute 
DCOM  Architecture  Overview,  10  Jan  97,  p.4.) 


COM  includes  interfaces  and  API  functions  that  expose  operating  system  services 
as  well  as  other  necessary  mechanisms  for  a  distributed  environment  such  as  naming  and 
events. 

DCOM  advantages  are: 

•  Microsoft  supports  DCOM  so  it  already  has  many  users. 

•  DCOM  and  the  other  Microsoft  tools  for  implementing  components  usually 
have  a  low  price. 

•  The  components  that  DCOM  integrates  can  be  implemented  in  many 
programming  languages  so  DCOM  succeeds  in  crossing  the  language 
boundaries. 

•  DCOM  offers  an  interface  that  crosses  network  boundaries  in  a  standard  and 
simple  way. 
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•  DCOM  is  a  robust  application.  It  is  easy  for  the  programmers  to  learn  to  use 
the  DCOM  (though  one  must  be  an  expert  in  areas  like  distributed  systems 
design,  multi-threaded  applications,  and  networking  to  implement  an 
embedded  system  with  DCOM). 

Disadvantages  of  DCOM  are: 

•  Once  an  interface  is  defined,  it  should  not  be  changed.  New  methods  should 
not  be  added  and  existing  methods  should  not  be  modified.  This  interface 
restriction  is  not  enforced,  but  it  is  a  rule  that  component  developers  should 
follow. 

•  DCOM  depends  on  the  Windows  Operating  System.  This  is  its  main 
disadvantage.  DCOM  does  not  satisfy  the  requirement  for  crossing  platform 
boundaries. 

•  Older  legacy  applications  are  not  easy  to  integrate  with  a  system  that  uses 
only  Windows. 

•  Because  COM  and  DCOM  are  based  on  a  native  binary  format,  components 
written  to  these  specifications  are  not  really  platform  independent. 

•  DCOM  is  not  standard  for  many  vendors.  For  example  Netscape  does  not 
support  ActiveX. 

•  DCOM  cannot  guarantee  high  performance. 

•  DCOM  does  not  support  security,  but  there  are  external  packages  for  security 
support. 

•  DCOM  does  not  support  applications  with  real-time  requirements  and  cannot 

guarantee  reliability  to  applications. 
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The  Common  Object  Request  Broker  Architecture10  (CORBA)  is  the  Object 
Management  Group's  (OMG)  solution.  OMG  is  an  industry  group  with  over  six  hundred 
member  companies  representing  computer  manufacturers,  independent  software  vendors, 
and  a  variety  of  government  and  academic  organizations.  CORBA  is  a  consortium 
standard,  not  a  "formal"  IEEE,  ANSI  or  ISO  standard. 

The  vision  behind  CORBA  is  that  distributed  systems  are  conceived  and 
implemented  as  distributed  objects.  The  interfaces  to  these  objects  are  described  in  a 
high-level,  architecture-neutral  specification  language  that  supports  object-oriented 
design  abstraction.  CORBA  supports  distributed  systems  that  feature  rapid  development, 
maintainability  and  adaptability. 
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Figure  5.  CORBA  Architecture  Layers  (Source:  Software  Engineering  Institute 
CORBA  Architecture  Overview,  10  Jan  97,  p.2.) 

Logically  the  CORBA  consists  of  4  layers  (Figure  5): 

•  The  Object  Request  Broker  (ORB)  layer  is  the  core  of  CORBA  and  it  handles 
requests  for  objects. 

•  The  CORBA  Common  Object  Services  Layer  or  CORBAServices  supplies 
the  object  support  service.  This  layer  is  fundamental  when  building  non-trivial 
distributed  applications.  These  services  currently  include  asynchronous  event 


10 


Kurt  Wallnau  in  his  technical  paper  "Common  Object  Request  Broker  Architecture' 
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management,  transactions,  persistence,  externalization,  concurrency,  naming, 
relationships,  and  lifecycle  management. 
•  CORBA  Common  Facilities  Layer  or  CORBAFacilities  has  two  sub-layers, 
the  horizontal  and  the  vertical.  They  may  be  useful  for  some  distributed 
applications,  but  are  not  as  universally  applicable  as  CORBAServices.  These 
facilities  include  user  interface,  information  management,  system 
management,  task  management,  and  a  variety  of  "vertical  market"  facilities  in 
domains  such  as  manufacturing,  distributed  simulation,  and  accounting. 
The   ApplicationObjects   Layer  is   an   extension   of  the   vertical   sub-layer  of 

CORBAFacilities  layer.  Developers  must  implement  this  layer  for  their  applications 

because  CORBA  offers  no  standard  solution. 
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Figure  6.  Detailed  CORBA  Architecture  (Source:  Software  Engineering  Institute 
CORBA  Architecture  Overview,  10  Jan  97,  p.3.) 

ORB  Core  is  the  CORBA  runtime  infrastructure.  The  interface  to  the  ORB  Core 

is  not  defined  by  CORBA.  It  is  proprietary  to  a  particular  vendor.  ORB  Interface  is  a 
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standard  interface  (defined  in  IDL)  to  functions  provided  by  all  CORBA-compliant 
ORBs. 

The  IDL  processor  generates  DDL  stubs  for  each  interface  defined  in  IDL.  Stubs 
hide  the  low-level  networking  details  of  object  communication  from  the  client  while 
presenting  a  high-level,  object  type-specific  application  programming  interface  (API). 

Dynamic  Invocation  Interface  (DII)  is  an  alternative  way  for  clients  to  access 
objects.  While  stubs  provide  an  object  type-specific  API,  DII  provides  a  generic 
mechanism  for  constructing  requests  at  run  time.  An  interface  repository  allows  some 
measure  of  type  checking  to  ensure  that  a  target  object  can  support  the  request  made  by 
the  client. 

Object  Adaptor  provides  extensibility  of  CORBA-compliant  ORBs  to  integrate 
alternative  object  technologies  into  the  OMA.  For  example,  adaptors  may  be  developed 
to  allow  remote  access  to  objects  that  are  stored  in  an  object-oriented  database.  Each 
CORBA-compliant  ORB  must  support  a  specific  object  adaptor  called  the  Basic  Object 
Adaptor  (BOA).  The  BOA  defines  a  standard  API  implemented  by  all  ORBs. 

IDL  Skeletons11  are  the  server-side  analogue  of  IDL  stubs.  IDL  skeletons  receive 
requests  for  services  from  the  object  adaptor  and  call  the  appropriate  operations  in  the 
object  implementation. 

Dynamic  Skeleton  Interface  (DSI)  is  the  server-side  analogue  of  the  DII.  While 
DDL  skeletons  invoke  specific  operations  in  the  object  implementation,  DSI  defers  this 


11  Jason  Pritchard  in  his  book  "COM  and  CORBA  Side  by  Side"  Jun  1999  p.  50 
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processing  to  the  object  implementation.  This  is  useful  for  developing  bridges  and  other 
mechanisms  to  support  inter-ORB  interoperation. 
Advantages  of  CORB A  are: 

•  CORBA  is  a  standard  architecture  for  Object  Request  Brokers.  CORBA 
compliant  vendors  support  portability  and  interoperability  across  different 
programming  languages,  hardware  platforms,  operating  systems,  and  ORB 
implementations. 

•  When  combined  with  the  Object  Management  Architecture,  CORBA  can 
result  in  distributed  systems  that  can  be  rapidly  developed  and  can  reap  the 
benefits  of  CORBA  like  maintainability  and  adaptability. 

•  CORBA  can  cross  network,  operating  systems  and  programming  language 
boundaries. 

•  CORBA  can  support  with  the  current  addition  of  Real-Time  Event  Service 
source  and  type  base  filtering,  event  correlations,  real-time  dispatching  and 
UDP/IP  multicast  communication.  Also  with  the  addition  of  Scheduling 
Service,  CORBA  can  support  static  rate  monotonic  scheduling  and  dynamic 
maximum  urgency  first  scheduling  to  assign  priorities  and  validate 
schedulability.  These  are  services  that  have  prevented  CORBA  from 
supporting  real-time  applications  and  guaranteeing  high  performance  in  the 
past. 

•  CORBA  makes  the  development  of  distributed  applications  easier  than  with 
previous  technologies. 
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•  CORBA  is  a  mature  product  with  a  large  and  growing  number  of  CORBA 
implementations  available  in  the  marketplace  including  implementations  from 
most  major  computer  manufacturers  and  independent  software  vendors. 

The  disadvantages  of  CORBA  are: 

•  CORBA  is  a  complex  specification  and  considerable  effort  is  required  to 
develop  expertise  in  its  use. 

•  CORBA  ORB's  vary  in  prices  from  vendor  to  vendor  and  some  ORB's  are 
very  expensive. 

•  There  is  no  organization  to  test  in  a  formal  way  all  aspects  of  a  CORBA 
implementation,  so  little  information  is  available. 

•  Changes  to  the  CORBA  specifications  while  technically  justified  have 
resulted  in  unstable  ORB  implementations. 

•  DDL  is  the  "least-common  denominator".  It  does  not  fully  exploit  the 
capabilities  of  programming  languages  especially  in  the  definition  of  abstract 
data  types. 

•  CORBA  specifies  only  a  minimal  range  of  security  mechanisms;  more 
ambitious  and  comprehensive  mechanisms  have  not  yet  been  adopted  by  the 
OMG. 

JINI  is  Sun  Microsystems'  distributed  computing  solution.  JINI  is  a  distributed 

system  that  allows  a  group  of  computing  devices  connected  by  an  Intranet  or  Internet  to 

be  used  by  a  group  of  users  as  a  single  computer  system.  Technically  JINI  system  extends 

the  Java  application  environment  from  a  single  virtual  machine  to  a  network  of  machines. 

The  JINI  system  is  Java  centric  and  assumes  that  all  the  co-operating  components  are 
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implemented  in  the  Java  programming  language.  It  is,  however,  possible  to  accept 
components  created  in  other  languages  if  their  compilers  can  produce  Java  byte  codes. 
The  high  level  goals  of  JINI  are: 

•  Enabling  users  to  share  services  and  resources  over  the  network. 

•  Providing  users  easy  access  to  resources  anywhere  on  the  network  while 
allowing  the  user's  network  location  to  change. 

•  Simplifying  the  task  of  building,  maintaining,  and  altering  a  network  of 
devices,  software  and  users 

The  logical  parts  of  JINI  that  try  to  satisfy  these  goals  are: 

•  A  set  of  components  that  provides  an  infrastructure  for  federating  services  in  a 
distributed  system. 

•  A  programming  model  that  supports  and  encourages  the  production  of  reliable 
distributed  services. 

•  Services   that   can   be   part   of  a   federated   JINI   system   and   that   offer 
functionality  to  any  other  member  of  the  federation. 

JINI  services  are  typically  computation,  storage,  or  communication  with  another 

service,  which  is  a  software  filter,  a  hardware  device,  or  another  user.  JINI  programmers 

must  think  in  terms  of  services  when  they  think  of  a  set  of  servers  and  clients,  users  and 

programs,  and  programs  and  files.  Users,  clients,  servers  do  not  exist  in  JINI;  everything 

is   a   service.    JINI   systems   provide   mechanisms   for   service   construction,    lookup, 

communication  and  use  in  a  distributed  system.  Examples  of  services  include  devices 

such  as  printers,  displays,  or  disks,  software  applications  or  utilities,  information  such  as 

databases  and  files,  and  users  of  the  system. 
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Services  in  a  JINI  system  communicate  to  each  other  using  a  service  protocol 
which  consists  of  interfaces  written  in  the  Java  programming  language.  The  set  of  such 
protocols  is  open-ended.  The  base  JINI  system  defines  a  small  number  of  such  protocols 
to  provide  critical  service  interactions. 

The  Lookup  Service  finds  and  resolves  other  services.  This  service  is  the  main 
mechanism  for  the  interaction  between  a  user  and  a  JINI  system.  Lookup  Service's  job  is 
to  know  the  available  interfaces  of  the  other  services  and  the  methods  and  functionality 
that  the  other  services  are  able  to  offer.  Thus,  when  a  user  requests  a  particular  service  the 
lookup  service  locates  the  appropriate  service  to  satisfy  the  user. 

Java  Remote  Method  Invocation  (RMI)  provides  the  communication  among 
services.  In  reality  it  is  not  a  service  but  an  infrastructure  that  supports  the 
communication  among  services.  RMI  provides  mechanisms  to  find,  activate,  and  garbage 
collect  object  groups.  It  provides  remote  procedures  call  mechanisms  that  allow  not  only 
the  interchange  of  data  among  the  objects,  but  also  the  interchange  of  whole  objects 
including  code  for  methods. 

JINI  supports  two  levels  of  security.  The  first  level  determines  if  the  user  of  the 
system  who  requests  the  service  has  the  right  to  use  this  particular  service.  The  second 
level  checks  if  a  service  has  the  right  to  request  another  service;  furthermore,  the 
relationships  among  services  are  maintained  in  the  access  control  list  responsible  for  this 
second  level  of  security. 

The  access  to  many  services  in  the  JINI  system  environment  is  based  on  leasing. 
Leasing  in  JINI  means  that  each  object  allocates  a  particular  service  for  particular  period 
of  time  using  predefined  rules.  JINI  offers  two  kinds  of  leasing  service,  exclusive  leasing 
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that  means  no  one  else  can  use  the  service  simultaneously  and  non-exclusive  leasing  that 
allows  the  reallocation  of  the  same  service  at  the  same  time  from  a  different  user  or 
object. 

The  JINI  Transaction  interfaces  provide  a  service  protocol  to  coordinate  a  two- 
phase  commitment.  A  series  of  operations,  either  within  a  single  service  or  spanning 
multiple  services,  can  be  wrapped  in  a  transaction.  The  semantics  of  a  transaction  is  left 
up  to  the  service  using  those  interfaces. 

The  JINI  architecture  supports  distributed  events  too.  An  object  may  allow  other 
objects  to  register  interest  in  events  in  the  object  and  receive  a  notification  of  the 
occurrence  of  the  event.  This  enables  distributed  event-based  programs  to  be  written  with 
a  variety  of  reliability  and  scalability  guarantees. 

The  components  of  the  JINI  system  can  be  segmented  into  three  categories 
infrastructure,  programming  model  and  services. 

Advantages  of  JINI  are: 

•  JINI  can  cross  network  and  operating  systems  boundaries. 

•  JINI  has  the  best  methodology  for  event  handling  for  the  communication 
between  objects. 

•  JINI  is  a  simple  technology  because  it  only  uses  Java's  environment. 
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Figure  7.  JINI  Architecture  Segmentation  (Source:  SUN  Microsystems  Inc.  JINI 
Architecture  Specification,  Jan  1999,  p.12.) 

•  In  JINI  it  is  easy,  natural  and  often  automatic  for  occurrences  to  join  and  leave 
the  system. 

•  JINI  systems  are  currently  far  more  dynamic  than  other  network  groups  which 
must  be  configured  by  hand  in  a  centralized  fashion. 

•  The  model  can  recognize  that  the  delivery  of  a  distributed  notification  may  be 
delayed. 

•  The  event  and  notification  interfaces,  which  are  an  extension  of  the  event 
model  used  by  JavaBeans  components  to  the  distributed  environment,  enable 
event-based  communication  among  JINI  services. 

The  disadvantages  of  JINI  are: 

•  The  JINI  architecture  gains  most  of  its  simplicity  by  assuming  that  the  Java 
programming  language  is  the  implementation  language  for  components. 

•  One  cannot  cross  language  boundaries  with  JINI  and  most  legacy  applications 
are  not  written  in  Java  so  they  must  be  rewritten  before  we  can  reuse  them 
with  JINI. 
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•     JINI  is  a  very  new  architecture  and  nobody  has  ever  used  it  extensively  in  the 
real  world  yet,  so  it  is  not  mature  enough. 

F.         COMPARISON  AMONG  THREE  ARCHITECTURES 

There  is  no  way  to  provide  a  complete  comparison  among  these  three  distributed 
computing  systems.  Any  comparison  depends  on  the  purpose  of  the  comparison  and  the 
background  of  the  audience. 

Parallels  among  the  main  operations  of  the  CORBA,  DCOM  and  JINI  include 
these: 

All  three  support  multiple  object  instantiation,  the  CORBA  and  JINI  through 
registration  and  skeleton  instantiation,  and  DCOM  by  the  server  explicitly  or  dynamically 
through  the  COM  run-time  system. 

DCOM  uses  the  Object  Remote  Procedure  Call  (ORPC),  CORBA  the  Internet 
Inter-ORB  Protocol  (HOP),  and  JINI  the  RMI  as  their  underlying  remote  protocols. 

When  a  client  object  needs  to  activate  a  server  object,  DCOM  can  do  it  by  a 
method  call;  on  the  other  hand  CORBA  offers  the  same  service  through  naming  or  trader 
service,  and  JINI  through  a  lookup  service. 

For  object  handling  the  client  for  DCOM  uses  an  interface  pointer  while  CORBA 
and  JINI  use  the  object  reference. 

The  Registry  in  DCOM  maps  object  names  as  does  the  Implementation 
Repository  in  CORBA,  and  the  RMIRegistry  in  JINI. 
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The  type  information  for  methods  is  held  by  Type  Library  in  DCOM,  by  Interface 
Repository  in  CORBA,  by  the  object  itself  in  JINI  which  can  be  queried  by  using 
reflection  and  introspection. 

The  responsibility  for  an  object's  location  and  activation  falls  to  Service  Control 
Management  (SCM)  with  DCOM,  to  Object  Request  Broker  (ORB)  for  locating  and  to 
Object  Adapters  for  activating  with  CORBA,  and  to  Lookup  Service  with  JINI. 

So  we  can  see  that  the  three  systems  have  very  similar  operations.  Other 
similarities  are: 

•  They  have  complex  ways  to  define  the  interface  of  their  components. 

•  They  require  that  the  user  know  networking  to  set  up  remote  services. 

•  They  can  cross  the  network  boundaries. 

•  They  offer  a  low  level  of  security. 

CORBA  is  the  most  complete  of  the  three.  First,  it  is  independent  of  language 
and  operating  system.  JINI  can  support  only  components  that  are  implemented  with  Java 
and  DCOM  works  properly  only  in  a  Windows  OS  environment.  Second,  CORBA  with 
the  addition  of  real-time  event  service  and  scheduling  can  be  reliable  enough  and  can 
offer  satisfactory  performance.  JINI  may  equal  CORBA  in  this  regard,  but  DCOM  does 
not.  Third,  CORBA  is  mature  enough.  Many  applications  have  already  been  implemented 
with  it.  DCOM  is  also  mature,  but  JINI  is  not.  CORBA  is  an  open  standard.  JINI  will  be 
offered  as  part  of  JAVA  and  DCOM  as  part  of  Windows.  Of  course,  CORBA  is  not  the 
perfect  solution  for  implementers  of  a  distributed  component  system  because  of  the  high 
level  of  effort  and  training  required  for  success. 
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III.  SOFTWARE  REQUIREMENTS  SPECIFICATION 

A.  OVERVIEW 

The  purpose  of  this  project  is  to  redesign  and  re-implement  the  CAMPEX 
Employment  Module  with  a  distributed  architecture  using  the  object-oriented 
methodology.  The  final  product  must  offer  to  the  Air  University  of  United  States  Air 
Force  a  tool  that  allows  students  to  improve  their  skills  in  air  campaign  design  through 
practice.  Also,  this  software  must  allow  students  to  execute  exercises  from  their  personal 
computers  and  transfer  the  results  of  their  practice  to  the  war  college  server. 

B.  CUSTOMERS 

The  customers  are  resident  students,  nonresident  students  and  instructors  at  the 
Air  University. 

C.  GOALS 

The  ultimate  goal  is  to  offer  an  application  to  Air  War  College  students  that 
allows  them  to  execute  exersices  in  air  campaign  planning.  This  application  will  also 
allow  instructors  at  the  Air  University  to  check  the  students'  results.  This  application 
must  be  capable  of  running  on  the  students  personal  computers  as  well  as  on  the  Air 
University  computers.  Thus,  the  CAMPEX  Employment  Module  must  offer: 

•  Fast  and  easy  downloading. 

•  Fast   and   easy   installation   on   computers   that   runs   Microsoft   Windows 

Operating  System  independent  of  the  configuration  of  the  students'  machines. 
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Selection  of  the  tactical  exercise  scenario. 

Cues  to  the  user  for  correctly  sequencing  events. 

Information  to  the  user  about  necessary  assumptions  used  during  the  exercise. 

Creation  and  editing  of  air  tasking  orders  (ATOs). 

Planning  of  the  missions. 

Automatic  update  of  the  game  state  with  the  execution  of  a  game  cycle. 

Creation  of  reports  with  the  results  and  estimations. 

The  ability  to  return  to  a  previous  state. 

Display  of  the  map  of  the  exercise  area. 

Analysis  of  the  student's  plan. 

Printing  of  reports,  results,  and  information  lists. 

D.  USER  CHARACTERISTICS 

The  typical  user  of  the  CAMPEX  Employment  Module  requires  special  education 
in  the  air  campaign  planning.  In  addition,  the  user  is  expected  to  have  a  medium  or  low 
level  of  familiarity  with  the  Windows  operating  system  and  the  Internet.  If  the  user  has 
these  characteristics  then,  he  will  be  able  to  use  the  module  after  a  brief  training  session 
that  will  take  approximately  two  to  three  hours. 

E.  GENERAL  CONSTRAINTS 

The  CAMPEX  Employment  Module  must  be  a  fully  autonomous  system  capable 
of  functioning  for  extended  periods  of  time  with  minimal  support.  The  CAMPEX 

prototype  will  be  provided  in  an  ACCESS-2000  runtime-software  package  that  will 
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include  all  the  required  bindings.  This  CAMPEX  Employment  Module  will  depend  on 
the  Windows  Operating  system  and  Microsoft  Office  commercial  product. 


F. 


ASSUMPTIONS  AND  DEPENDENCIES 


The  following  assumptions  and  dependencies  have  been  defined  in  order  to 
simplify  the  analysis  of  the  CAMPEX  Employment  Module  and  the  implementation  of 
the  CAMPEX  Employment  Module  prototype. 

1.  The  user  (student)  must  know  how  to  operate  a  personal  computer  and  more 
specifically  how  to  use  a  personal  computer  that  runs  Microsoft  Windows 
operating  system. 

2.  In  this  initial  phase  only  the  employment  module  prototype  will  be 
implemented. 

3.  The  software  application  will  fully  support  the  basic  functionality  of  the 
CAMPEX  Employment  Module  and  partially  support  the  optional 
functionality. 

4.  The  user  must  be  connected  to  the  Internet  to  execute  the  "Send  Exercise" 
function. 

G.        SYSTEM  FUNCTIONS 


Ref# 

Function 

Use  Case 

Category 

Rl 

Student  Support  Functions 

Rl.l 

Creates  and  displays  new  Student  Card 

Ul 

evident 

R1.2 

Stores  new  Student  attributes  into  the 
objects  repository  (database) 

Ul 

hidden 
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Ref# 

Function 

Use  Case 

Category 

R1.3 

Displays  existed  Students 

Ul 

evident 

R1.4 

Displays  current  student's  attributes 

Ul 

evident 

R1.5 

Logs  attributes  changes  to  a  student's  object 

Ul 

evident 

R1.6 

Changes  the  object  student  attributes 

Ul 

hidden 

R1.7 

Searches  student  objects  instantiations  with 
input  key 

Ul 

hidden 

R2 

Send  Exercise  Functions 

R2.1 

Displays  existent  Exercises  objects 

U2 

evident 

R2.2 

Queries  Exercises  objects  with  input  key 

U2 

hidden 

R2.3 

Outputs  the  collected  exercise  attributes  to 
Air  University  database 

U2 

hidden 

R2.4 

Displays  message  that  informs  student  for 
the  success  of  the  process 

U2 

evident 

R3 

Starts  a  CAMPEX  module  (Employment) 
Functions 

R3.1 

Retrieves  the  "Copyright  Screen"  from 
database 

U3 

hidden 

R3.2 

Displays  the  "Copyright  Screen" 

U3 

evident 

R3.3 

Retrieves  the  "Execute  Order"  from 
database 

U3 

hidden 

R3.4 

Displays  the  "Execute  Order" 

U3 

evident 

R3.5 

Provides  inter-process  communication 
mechanisms 

U3 

evident 

R3.6 

Retrieves  the  "DIA  Intel  Update"  from 
database 

U3 

hidden 

R3.7 

Displays  the  "DIA  Intel  Update" 

U3 

evident 

R3.8 

Retrieves  record  the  "Thai  Forces 
Available"  from  database 

U3 

hidden 
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Ref# 

Function 

Use  Case 

Category 

R3.9 

Displays  the  "Thai  Forces  Available"  List 

U3 

evident 

R3.10 

Retrieves  the  "Weather  Report"  from 
database 

U3 

hidden 

R3.ll 

Displays  the  "Weather  Report" 

U3 

evident 

R3.12 

Retrieves  the  "Navy  Update"  from  database 

U3 

hidden 

R3.13 

Displays  the  "Navy  Update" 

U3 

evident 

R3.14 

Retrieves  the  "Weapon  Availability  Update" 
from  database 

U3 

hidden 

R3.15 

Displays  the  "Weapon  Availability  Update" 

U3 

evident 

R3.16 

Retrieves  record  of  "Program  Notes"  from 
database 

U3 

hidden 

R3.17 

Displays  "Program  Notes" 

U3 

evident 

R3.18 

Retrieves  the  of  "Bomb  Damages 
Assessment  and  Targets  Definitions"  from 
database 

U3 

hidden 

R3.19 

Displays  the  "Bomb  Damages  Assessment 
and  Targets  Definitions" 

U3 

evident 

R3.20 

Retrieves  the  "Analysis  and  Corrections" 
from  database 

U3 

hidden 

R3.21 

Displays  the  "Analysis  and  Corrections" 

U3 

evident 

R3.22 

Retrieves  the  "Read  me  file  for  Employment 
Module"  from  database 

U3 

hidden 

R3.23 

Displays  the  "Read  me  file  for  Employment 
Module"  text 

U3 

evident 

R4 

ATO  Support  Functions 

R4.1 

Initiates  a  new  ATO  object  with  the  name 
given  by  user 

U4 

evident 

R4.2 

Loads  an  existent  ATO 

U4 

evident 

35 


Ref# 

Function 

Use  Case 

Category 

R4.3 

Copy  an  existent  ATO  to  a  new  one  with  a 
name  given  by  user 

U5 

evident 

R4.4 

Renames  an  existent  ATO 

U4 

evident 

R4.5 

Erases  an  existent  ATO 

U4 

evident 

R4.6 

Displays  an  ATO  enter  form  to  enter  ATO 
attributes 

U4 

evident 

R5 

Support  Planning  Missions  Functions 

R5.1 

Enters  a  target  to  the  priority  list 

U6 

evident 

R5.2 

Decreases  the  priority  of  the  existed  targets 
with  lower  priority  than  the  specified 
priority  by  one 

U6 

evident 

R5.3 

Increases  the  priority  of  the  existed  targets 
with  higher  priority  than  the  specified 
priority  by  one 

U6 

evident 

R5.4 

Deletes  the  targets  with  priority  lower  than 
20 

U7 

evident 

R5.5 

Creates  and  displays  a  new  mission  card 

U7 

evident 

R5.6 

Stores  new  mission  record  to  database 

U7 

hidden 

R5.7 

Displays  a  mission  object 

U7 

evident 

R5.8 

Logs  attributes  to  a  mission  object 

U7 

evident 

R5.9 

Search  Missions  objects  with  input  key 
(mission  or  package) 

U7 

hidden 

R5.10 

Deletes  a  Mission  object 

U7 

evident 

R6 

Fly  an  ATO  Support  Functions 

R6.1 

Executes  the  assigned  missions  and 
packages 

U8 

hidden 

R6.2 

Collects  all  assigned  missions,  packages, 
and  actual  data  objects 

U8 

hidden 

R6.3 

Calculates  the  collected  objects 

U8 

hidden 
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Ref# 

Function 

Use  Case 

Category 

R6.4 

Creates  a  new  ATO  state 

U8 

evident 

R6.5 

Save  the  calculation's  results  as  attributes  of 
the  new  ATO  state 

U8 

hidden 

R7 

Initial  Information  Support  Functions 

R7.1 

Queries  data  base  for  Blue  Bases  objects 

U9 

hidden 

R7.2 

Displays  total  Basing  Information 

U9 

evident 

R7.3 

Queries  database  for  sorties  attributes 

U9 

hidden 

R7.4 

Calculates  the  queries'  results 

U9 

hidden 

R7.5 

Displays  available  sorties  by  Blue  Bases 

U9 

evident 

R7.6 

Queries  database  for  the  necessary  for 
analysis  objects 

U9 

hidden 

R7.7 

Calculates  the  queries' results 

U9 

hidden 

R7.8 

Displays  the  missions'  analysis 

U9 

evident 

R7.9 

Queries  the  database  for  Ground  Forces 
objects 

U9 

hidden 

R7.10 

Displays  the  collected  by  the  queries  objects 

U9 

evident 

R8 

Estimated  Results  Support  Functions 

R8.1 

Queries  database  for  Recce  by  target 

U10 

hidden 

R8.2 

Displays  Recce  by  targets  for  the  current 
program  state 

U10 

evident 

R8.2.1 

Queries  database  for  missions  and  actual 
information  objects 

U10 

hidden 

R8.3 

Calculates  the  collected  objects 

U10 

hidden 

R8.4 

Displays  estimated  results  of  planned 
missions  before  the  missions  execution 

U10 

evident 

R8.5 

Queries  database  for  missions  that  have  the 
attribute  sorties  =  empty 

U10 

hidden 

R8.6 

Displays  missions  without  sorties 

U10 

evident 
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Ref# 

Function 

Use  Case 

Category 

R8.7 

Queries  database  for  necessary  objects  to 
calculates  the  "daily  summary" 

U10 

hidden 

R8.8 

Calculates  the  queries  (R8.7)  results  to 
create  daily  summary 

U10 

hidden 

R8.9 

Displays  daily  summaries  by  Aircraft  Type 

U10 

evident 

R8.10 

Displays  daily  summaries  by  Task  Type 

U10 

evident 

R8.ll 

Queries  database  for  necessary  objects 
attributes  to  create  the  "logistics 
requirements" 

U10 

hidden 

R8.12 

Calculates  the  results  of  the  (R8.1 1)  queries 
to  create  the  report 

U10 

hidden 

R8.13 

Displays  logistics  requirements  by  Blue 
Base  and  Supply  category 

U10 

evident 

R9 

Actual  Results  Support  Functions 

R9.1 

Queries  database  for  necessary  objects  to 
create  "the  cumulative  summary  report" 

Ull 

hidden 

R9.2 

Calculates  the  collected  objects  attributes  of 
query  (R9.1) 

Ull 

hidden 

R9.3 

Displays  cumulative  summary  with  the  end 
of  past  date 

Ull 

evident 

R9.4 

Queries  database  for  the  necessary  objects 
for  the  report  "Recce  Targets  at  the  start  of 
the  current  Date" 

Ull 

hidden 

R9.5 

Calculates  the  results  of  query  (R9.5) 

Ull 

hidden 

R9.6 

Displays  Recce  for  Targets  at  the  start  of  the 
current  date 

Ull 

evident 

R9.7 

Queries  the  database  for  the  necessary 
objects  to  create  the  report  "Enemy  Planes 
over  Blue  Bases  during  the  Past  Day" 

Ull 

hidden 
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Ref# 

Function 

Use  Case 

Category 

R9.8 

Calculates  the  results  of  query  (R9.7) 

Ull 

hidden 

R9.9 

Displays  the  number  of  enemy  planes  over 
the  Blue  Bases  during  the  past  date 

Ull 

evident 

R9.10 

Queries  the  database  for  the  necessary 
objects  to  create  the  report  of  "Overall 
Indicators  of  Sorties  at  the  end  of  the  Past 
Date" 

Ull 

hidden 

R9.ll 

Calculates  the  results  of  query  (R9.10) 

Ull 

hidden 

R9.12 

Displays  overall  indicators  of  sorties  at  the 
end  of  the  past  date 

Ull 

evident 

R9.13 

Queries  the  database  for  the  necessary 
objects  to  create  the  report  of  "Overall 
Indicators  of  Effort  Weight  at  the  End  of  the 
Past  Date  " 

Ull 

hidden 

R9.14 

Calculates  the  results  of  query  (R9.13) 

Ull 

hidden 

R9.15 

Displays  overall  indicators  of  effort  weight 
at  the  end  of  the  past  date 

Ull 

hidden 

R9.16 

Queries  the  database  for  the  necessary 
objects  to  create  the  report  of  "Overall 
Indicators  of  Blue  Attrition  at  the  End  of  the 
Past  Date" 

Ull 

hidden 

R9.17 

Calculates  the  results  of  query  (R9.16) 

Ull 

hidden 

R9.18 

Displays  overall  indicators  of  Blue  Attrition 
at  the  end  of  the  past  date 

Ull 

evident 

R9.19 

Queries  the  database  for  the  necessary 
objects  to  create  the  report  of  "Overall 
Indicators  of  Loss  Ratio  at  the  End  of  the 
Past  Date  " 

Ull 

hidden 

R9.20 

Calculates  the  results  of  query  (R9.19) 

Ull 

hidden 
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Ref# 

Function 

Use  Case 

Category 

R9.21 

Displays  overall  indicators  of  loss  ratio  at 
the  end  of  the  past  date 

Ull 

evident 

R9.22 

Queries  the  database  for  the  necessary 
objects  to  create  the  report  of  "Losses  by 
Mission  and  by  Task  Type  During  the  Past 
Date" 

Ull 

hidden 

R9.23 

Calculates  the  results  of  query  (R9.22) 

Ull 

hidden 

R9.24 

Displays  losses  by  mission  and  by  task  type 
during  the  past  date 

Ull 

evident 

R9.25 

Queries  the  database  for  the  necessary 
objects  to  create  the  report  of  "Losses  by 
Mission  and  by  Aircraft  Type  During  the 
Past  Date  " 

Ull 

hidden 

R9.26 

Calculates  the  results  of  query  (R9.25) 

Ull 

hidden 

R9.27 

Displays  losses  by  mission  and  by  aircraft 
type  during  the  past  date 

Ull 

evident 

RIO 

Support  Functions  of  General  Purpose 

RIO.l 

Loads  the  ATO  Management  screen 

U3 

optional 

R10.2 

Loads  the  program  Main  Menu  screen 

U4,U5 

optional 

R10.3 

Displays  Operations  Area  Map 

U12 

optional 

R10.4 

Quit  the  program 

None 

optional 

R10.5 

Changes  time  of  displaying  messages  on  the 
screen  1-5  sec 

None 

optional 

R10.6 

Changes  color  of  the  screen 

None 

optional 

R10.7 

Locked  keypad  to  arrows  Yes/No 

None 

optional 

R10.8 

Convert  box  characters  Yes/No 

None 

optional 

R10.9 

Showing  bombing  on  map  Yes/No 

None 

optional 
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Ref# 

Function 

Use  Case 

Category 

R10.10 

Highlights  steel  for  LCD/Mono  screen 
Yes/No 

None 

optional 

RlO.ll 

Displays  warning  messages 

ALL 

optional 

R10.12 

Displays  reminder  messages 

ALL 

optional 

R  10.13 

Displays  additional  explanation  messages 

ALL 

optional 

R10.14 

Displays  interactive  messages 

ALL 

optional 

Table  1.  System  Functions 


H.        SYSTEM  ATTRIBUTES 


Attribute 

Details  and  Boundary  Constraints 

Response  time 

When  entering  new  values,  the  system 
must  give  the  opportunity  to  enter  the  next 
item  in  1  sec. 

Response  time 

When  user  asks  to  see  a  report  or 
information  list,  system  must  displays  the 
report  on  the  screen  in  5  sec 

Response  time 

System  must  execute  an  ATO  and  moves  to 
the  next  state  in  5  sec 

Response  time 

System  must  start  printing  the  reports  in  15 
sec 

Interface  metaphor 

Forms-metaphor  windows  and  dialog  boxes 

Operating  system  platform  (initially) 

Microsoft  Windows  95  and  NT 

Table  2.  System  Attributes 
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I. 


USE  CASES 


1.  High  Level  Use  Cases 


Ul:  Start  Employment  Module 

U2:  Student  Info 

U3:  Load  an  ATO 

U4:  Manage  an  ATO 

U5:  Describes  the  20  Targets  with  Highest  Priority 

U6:  Plan  an  ATO 

U7:  Fly  an  ATO 

U8:  Initial  Information 

U9:  Estimated  Results 

U10:  Actual  Results 

UlLMap 

U12:  Send  Exercise 


USE  CASE  (Ul):  START  EMPLOYMENT  MODULE 

Actors:  Student 


Purpose: 
Overview: 


Type: 

Cross  References: 


Start  the  Employment  Module 

Student  selects  to  use  the  CAMPEX  Employment  Module,  the 

program  displays  the  Introduction  Reports  and  "Ground  Forces 

Report".  The  student  can  select  to  see  only  the  "Ground  Forces 

Report"  and  as  alternative  to  continue  with  the  program. 

Primary  and  essential 

R3,  R3.1,  R3.2,  R3.3,  R3.4,  R3.5,  R3.6,  R3.7,  R3.8,  R3.9,  R3.10, 

R3.ll,  R3.12,  R.3.13,  R3.14,  R3.15,  R3.16,  R3.17,  R3.19,  R3.20, 

R3.21,R3.22,R7.9,  R7.8 
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USE  CASE  (U2):  STUDENT  INFO 

Actors:  Student 

Purpose:  Student  identifies  himself 

Overview:  Student  enters  his  Personal  Information  in  the  CAMPEX.  If  he  has 

already  entered  his  personal  information,  he  just  selects  his  own 


Type: 

Cross  References: 


name. 

Primary  and  essential 

Rl.l,  R1.2,  R1.3,  R1.4,  R1.5,  R1.6,  R1.7,  R10.1 1,  R10.12, 

R10.13,  R10.14,  R10.15 


USE  CASE  (U3):  LOAD  AN  ATO 
Actors:  Student 

Purpose:  Load  an  ATO 

Overview:  Student  selects  an  ATO  to  load.  When  completed,  student  will 

enter  the  "Main  Menu"  and  the  selected  ATO  is  loaded. 


Type: 

Cross  References: 


Primary  and  essential 

R4.2,  R10.1,  R10.1 1,  R10.12,  R10.13,  R10.14 

Use  Cases:  Student  must  have  completed  the 

•  "Start  Employment  Module"  Use  Case  (Ul) 

•  "Student  Info"  Use  Case  (U2) 


Actors: 
Purpose: 


USE  CASE  (U4):  MANAGE  AN  ATO 

Student 


To  allow  student  to  manage  to  the  ATO's 
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Overview: 


Type: 

Cross  References: 


Student  wants  to  manage  to  an  ATO.  When  completed,  student  will 

return  in  the  "ATO  File  Management"  menu  and,  he  can  continue 

by  loading  an  ATO. 

Primary  and  essential 

R4.1,  R4.3,  R4.4,  R4.5,  R4.6,  R10.1,  R10.1 1,  R10.12,  R10.13, 

R10.14 

Use  Cases:  Student  must  have  completed  the 

•  "Start  Employment  Module  "  Use  Case  (Ul) 

•  "Student  Info"  Use  Case  (U2) 


USE  CASE  (US):  DESCRIBE  THE  20  TARGETS  WITH  HIGHEST 
PRIORITY 

Actors:  Student 

Purpose:  Fill  the  list  with  20  targets  with  highest  priority 

Overview:  Student  has  decided  which  targets  of  his  plan  have  the  highest 

priority.  Student  edits  the  list  of  20  targets  with  highest  priority. 

After  the  completion  of  this  use  case,  the  student's  "20  Highest 

Priority  Target  List"  can  be  displayed  by  the  application. 

Primary  and  essential 

R5.1,  R5.2,  R5.3,  R5.4,  R10.2,  R10.1 1,  R10.12,  R10.13,  R10.14 

Use  Cases:  Student  must  have  completed: 

•  "Start  Employment  Module"  Use  Case  (Ul) 

•  "Student  Info"  Use  Case  (U2) 


Type: 

Cross  References: 
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Actors: 

Purpose: 

Overview: 

Type: 

Cross  References: 


•  "Load  an  ATO"  Use  Case  (U3) 

USE  CASE  (U6):  PLAN  AN  ATO 
Student 

Enters  student's  plans 

Student  enters  new  missions  or  edits  old  missions.  With 
completion  of  this  use  case  the  student's  plans  have  been  entered. 
Primary  and  essential 

R5.5,  R5.6,  R5.7,  R5.8,  R5.9,  R5.10,  R10.2,  R10.1 1,  R10.12, 
R10.13,  R10.14 
Use  Cases:  Student  must  have  completed: 

•  "Stan  Employment  Module"  Use  Case  (U 1 ) 

•  "Student  Info"  Use  Case  (U2) 

•  "Load  an  ATO"  Use  Case  (U3) 


USE  CASE  (U7):  FLY  AN  ATO 
Actors:  Student 

Purpose:  To  execute  the  planned  missions 

Overview:  Student  is  running  fly  missions.  System  calculates  the  result  of  the 

planned  missions.  Saves  the  results  in  a  new  ATO.  Loads  the  new 

ATO. 
Type:  Primary  and  essential 

Cross  References:         R6.1,  R6.2,  R6.3,  R6.4,  R6.5,  R10.2,  R10.1 1,  RIO.  12,  RIO.  13, 

R10.14 
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Use  Cases:  Student  must  have  completed: 

•  "Start  Employment  Module"  Use  case  (Ul) 

•  "Student  Info"  Use  Case  (U2) 

•  "Load  an  ATO"  Use  Case  (U3) 

•  "Plan  an  ATO"  Use  Case  (optional)  (U6) 


Type: 

Cross  References: 


USE  CASE  (U8):  INITIAL  INFORMATION 

Actors:  Student 

Purpose:  Inform  student  for  the  initial  data  of  an  ATO 

Overview:  Student  asks  for  initial  information.  With  completion  of  this  use 

case,  the  student  has  seen  or  printed  the  information  that  he  has 

asked  for. 

Primary  and  essential 

R7.1,  R7.2,  R7.3,  R7.4,  R7.5,  R7.6,  R7.7,  R7.8,  R7.9,  R7.10, 

R10.2,  R10.1 1,  R10.12,  R10.13,  R10.14 

Use  Cases:  Student  must  have  completed: 

•  "Start  Employment  Module"  Use  Case  (U 1 ) 

•  "Student  Info"  Use  Case  (U2) 

•  "Load  an  ATO"  Use  Case  (U3) 

USE  CASE  (U9):  ESTIMATED  RESULTS 

Actors:  Student 

Purpose:  Display  the  estimated  results  of  the  student  plan  before  executing 

the  plan 
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Overview: 

Type: 

Cross  References: 


Student  asks  for  the  estimated  results.  With  completion  of  this  use 

case  estimated  results  are  displayed  on  the  screen. 

Primary  and  essential 

R8.1,  R8.2,  R8.3,  R8.4,  R8.5,  R8.6,  R8.7,  R8.8,  R8.9,  R8.10, 

R8.ll,  R8.12,  R8.13,  R10.2,  R10.1 1,  R10.12,  R10.13,  R10.14 

Use  Cases:  Student  must  have  completed: 

•  "Start  Employment  Module"  Use  Case  (Ul) 

•  "Student  Info"  Use  Case  (U2) 

•  "Load  an  ATO"  Use  Case  (U3) 

•  "Plan  an  ATO"  Use  Case  (optional)  (U6) 


Actors: 

Purpose: 

Overview: 

Type: 

Cross  References: 


USE  CASE  (U10):  ACTUAL  RESULTS 

Student 

Inform  student  of  the  Results  Reports  of  an  ATO 

Student  asks  for  information.  With  completion  of  this  use  case,  the 

student  has  seen  or  printed  the  information  that  he  has  asked  for. 

Primary  and  essential 

R9,  R9.1,  R9.2,  R9.3,  R9.4,  R9.5,  R9.6,  R9.7,  R9.10,  R9.1 1, 

R9.12,  R9.13,  R9.14,  R9.15,  R9.16,  R9.17,  R9.18,  R9.19,  R9.20, 

R9.21,  R9.22,  R9.23,  R9.24,  R9.25,  R9.26,  R9.27,  R10.2,  RIO.  11, 

R10.12,  R10.13,  R10.14 

Use  Cases:  Student  must  have  completed: 

•     "Start  Employment  Module"  Use  Case  (Ul) 
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'Student  Info"  Use  Case  (U2) 


"Load  an  ATO"  Use  Case  (U3) 


"Fly  an  ATO"  Use  Case  (U7) 


Actors: 

Purpose: 

Overview: 

Type: 

Cross  References: 


USE  CASE  (Ull):  MAP 

Student 

See  the  map  of  the  exercise  area 

Student  selects  to  see  the  map  via  the  Main  Menu.  When 

completed,  the  map  is  displayed  on  the  screen. 

Primary  and  essential 

R10.2,R10.3 


Actors: 

Purpose: 

Overview: 


Type: 


Use  Cases:  Student  must  have  completed: 

•  "Start  Employment  Module"  Use  Case  (U 1 ) 

•  "Load  an  ATO"  Use  Case  (U3) 

USE  CASE  (U12):  SEND  EXERCISE 

Student 

To  send  the  results  of  an  exercise  to  "Air  University" 

Student  must  be  connected  to  the  "internet"  first.  Then,  selects  the 

Option  "Send  Exercise  Results  to  the  Air  University"  and  selects 

an  exercise  from  the  displayed.  With  the  completion  of  this  use 

case,  the  selected  exercise  results  are  sent  to  the  Air  University 

server. 

Primary  and  essential 
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Cross  References:         R2.1,  R2.2,  R2.3,  R2.4,  R10.15 

Use  Cases:  User  must  have  completed  the 

•  "Student  Info"  Use  Case  (U2) 

•  User  must  have  connected  to  the  Internet 

2.  CAMPEX  Employment  Module  Use  Case  Diagram 

User  starts  the  CAMPEX  by  identifying  himself,  and  by  this  way  the  results  of  the 
exercise  execution  will  have  an  owner.     ■  • 

Then  the  user  selects  to  start  the  CAMPEX  Employment  module. 

The  last  use  case  that  is  described  by  the  CAMPEX  Employment  Module  use  case 
diagram  is  "Send  Exercise."  With  this  use  case,  the  user  can  send  the  results  of  an 
exercise  to  the  Air  War  College  server.  The  sent  results  have  the  user  ID  and  the  Air  War 
College  Instructors  can  identify  the  owner. 
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Dependency  from 
Actor  Actions 


Dependency  from 
other  Use  Case 


Figure  8.  Use  Cases  Diagram 


J. 


RANKING  USE  CASES 


Rank 

Use  Case 

Justification 

High 

Load  an  ATO  (U3) 

Important  because  it 
initiates  the  Employment 
module. 

Fly  ATO  (U7) 

Most  important  and  highest 
risk  process. 

Plan  an  ATO  (U6) 

Important  because  it  allows 
the  student  enter  his  plan. 

Medium 

Describes  the  20  targets  with  highest 
priority  (U5) 

Important  because  it  allows 
the  student  to  enter  his  plan 
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Rank 

Use  Case 

Justification 

Medium 

Student  Info  (U2) 

Affects  the  identification  of 
the  exercise  results. 

Start  CAMPEX  Employment  Module 
(Ul) 

Affects  the  initial  phase  of 
the  CAMPEX 

Send  Exercise  (U12) 

Affects  the  process  of 
ranking  the  exercises. 

Manage  an  ATO  (U4) 

Affects  the  initial  phase  of 
the  module. 

Initial  Information  (U8) 

Informs  student  about  the 
current  data. 

Estimated  Results  (U9) 

Informs  student  about  the 
changes  that  will  happen  to 
the  data. 

Actual  Results  (U 10) 

Informs  student  about  the 
new  state  data. 

Low 

Map  (U 12) 

Minimum  effect  on  the 
processes 

Table  3.  Ranking  Use  Cases 
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Figure  9.  Conceptual  Model. 
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IV.   SOFTWARE  DESIGN  SPECIFICATION  (SDS) 
A.         INTRODUCTION 

1.  Purpose 

This  chapter  specifies  the  design  for  the  Campaign  Planning  Exercises 
(CAMPEX)  Employment  Module  and  presents  the  interaction  (collaboration)  and  object 
diagrams  that  describe  the  overall  CAMPEX  Employment  Module  software. 

2.  Scope 

This  SDS  provides  extensive  information  concerning  the  designed  and  proposed 
functionality  of  the  CAMPEX  Employment  Module.  This  chapter  describes  the 
subsystems  that  comprise  the  CAMPEX  Employment  Module.  The  sequence  diagrams 
describe  the  individual  CAMPEX  object  interactions  via  messages/methods.  The  object 
diagrams  illustrate  the  specifications  for  software  classes  and  the  interfaces  for  the 
CAMPEX  Employment  Module. 

3.  Definitions,  Acronyms,  and  Abbreviations 

All  definitions,  acronyms,  and  abbreviations  are  included  in  Appendix  C: 
"Abbreviations,  Acronyms,  and  Definitions".  Abbreviations,  acronyms,  and  definitions 
from  the  previous  chapter  have  been  carried  forward  for  consistency. 
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B.  THE  SYSTEM  ARCHITECTURE 


1.  The  Detailed  Architecture  Diagram 
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Figure  10.  Detailed  Architecture  Diagram. 

The  CAMPEX  Employment  Module  has  three  subsystems.  The  Presentation 
Subsystem/Layer  contains  the  Graphical  User  Interfaces  (GUIs).  The  Application 
Subsystem/Layer  contains  the  CAMPEX  Employment  Module  high  level  object-oriented 
services,  the  services  for  communication  with  external  devices  and  interface  to  the  local 
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and  remote  database  (Server  of  the  Air  War  College).  The  Storage  Subsystem  contains 
the  actual  database. 

a.  Presentation  Subsystem 

•  Object  Class:  Graphical  User  Interface. 

•  Interface  to  Other  Subsystems:  Application  Subsystem. 

•  Human  Interface:  The  GUI  provides  the  only  interface  to  the  user  of 
the  CAMPEX  employment  Module.  Chapter  V  User  Manual  provides 
a  pictorial  representation  of  the  CAMPEX  Employment  Module 
human  interfaces. 

•  Overall  Control  Structure:  The  GUI  is  consisting  of  a  number  of 
Microsoft  ACCESS  2000  Forms  and  Sub-forms. 

•  Resource  Allocation:  The  GUI  first  allocates  resources  that  support  the 
system  screen  and  then  allocates  part  of  the  system  processing  power 
and  data  storage  space. 

•  Data  Stores  and  Management:  The  GUI  subsystem  does  not  store  or 
manage  data;  it  has  no  direct  access  to  data,  but  it  does  offer  a 
communication  channel  between  the  user  and  the  Application 
Subsystem. 

•  Global  Resources  and  Management:  The  management  of  the  global 
resources  associated  with  the  three  CAMPEX  Employment  Module 
Subsystems  is  conducted  through  a  time-sharing  approach.  Resources 
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are  not  shared  equally  among  all  the  subsystems.  The  GUI  uses  most 
of  the  resources  that  support  the  screen  operation,  for  example. 

•  Boundary  Conditions:  None. 

•  Constraints:  The  GUI  of  CAMPEX  Employment  Module  cannot  be 
made  autonomous  from  the  other  subsystems  of  the  CAMPEX 
Employment  Module.  The  entire  CAMPEX  Employment  Module 
prototyping  will  be  provided  in  a  Microsoft  ACCESS  2000  runtime 
software  package  that  includes  all  required  bindings. 

•  Trade-Off  Priorities:  None. 

•  Design  Decision  /Rationale: 

•  The    GUI   provides    the    only    external    interface    to    CAMPEX 
Employment  Module. 

•  ACCESS  2000  will  be  used  in  the  GUI  Subsystem. 

•  All  Forms  and  Sub-Forms  are  considered  essential. 

b.  Application  Subsystem 

•  Object  Class:  See  Figure  11. 

•  Interface  to  Other  Subsystems:  Presentation  Subsystem. 

•  Human  Interface:  None 

•  Overall  Control  Structure:  The  CAMPEX  Employment  Module 
prototype  uses  sequential  method  to  control  its  tasks,  with  one  active 
object  to  monitor  and  control  all  tasks.  The  CAMPEX  Employment 
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Module  is   procedurally  driven;   it  uses  fixed  procedural  loops  to 
control  the  system. 

•  Resource  Allocation:  Allocation  of  resources  is  focused  towards  the 
timed  processes  required  to  monitor  the  GUI.  A  process  that  also  sends 
objects  to  the  Air  War  College  allocates  communication  resources. 

•  Data  Stores  Management:  The  Data  Base  Subsystem  is  responsible  for 
the  management  and  storage  of  the  data.  The  Application  Subsystem 
has  direct  access  to  the  data  storage  resources. 

•  Global  Resources  and  Management:  The  objects  within  the 
Application  Subsystem  share  the  resources  equally. 

•  Boundary  Conditions:  Startup,  shutdown,  termination,  and  failure 
should  be  performed/investigated  by  the  system  user.  Details  are 
provided  in  the  user's  manual  in  Chapter  V. 

•  Constraints:  Employment  Module  prototype  can  be  used  as  fully 
autonomous  system  when  packaged  as  a  Microsoft  ACCESS  2000 
run-time  including  all  the  required  bindings.  Otherwise  it  can  only 
work  through  Microsoft  ACCESS  2000.  Furthermore,  the  user  must 
establish  an  Internet  connection  first  to  communicate  and  send 
information  to  the  Air  War  College  Server. 

•  Trade-Off  Priorities:  None 

•  Design  Decision/Rationale: 

•     Efforts  were  taken  to  minimize  the  use  cases  but  the  number  was 

constrained  by  the  required  functionality. 
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•  The  CAMPEX  Employment  Module  fully  supports  all  physically 
challenged  persons. 

•  Visual  Basic  and  SQL  will  be  used  through  Microsoft  ACCESS 
2000  in  the  Application  Subsystem. 

•  All  functions  are  considered  essential. 

•  For  the  communication  with  the  Air  War  College  Server  a  DSN 
address  will  be  used. 

c.  Storage  Subsystem 

•  Object  Class:  Data  Base 

•  Interface  to  Other  Subsystems:  Application  Subsystem. 

•  Human  Interface:  None 

•  Overall  Control  Structure:  The  Data  Base  consists  of  a  number  of 
tables  and  various  types  of  queries. 

•  Resource  Allocation:  The  Data  Base  uses  about  10  MB  of  hardware 
storage  in  the  system  at  any  time  and  allocates  additional  space  for 
queries. 

•  Data  Stores  and  Management:  Microsoft  ACCESS  2000  handles  the 
storage  for  the  Data  Base. 

•  Global  Resources  and  Management:  As  described  above  in  Resource 
Allocation. 

•  Boundary  Conditions:  None. 
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•  Constraints:  Data  Base  is  constrained  by  the  ACCESS  2000  general 
constraints. 

•  Trade-Off  Priorities:  None. 

•  Design  Decision/Rationale: 

•  ACCESS  2000  will  be  used  in  the  Data  Base  Subsystem. 

•  DSN  address  describes  the  address  of  the  Air  War  College  Server. 

•  All  functions  are  considered  essential. 

•  The  user  has  no  direct  access  to  the  Data  Base. 
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C.        OBJECT/CLASS  DIAGRAMS 


1.  Object  Diagram 
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Figure  11.  CAMPEX  Employment  Module  Object. 
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2.  Classes-Objects  Attributes  and  Operations 


a.  Class  Employ 


1/ 


Attributes 


Attribute 

Type 

Description 

Hi_5Damage 

Integer 

Parameter  for  calculation 

Lo_5Damage 

Integer 

Parameter  for  calculation 

Hi_7Damage 

Integer 

Parameter  for  calculation 

Lo_7Damage 

Integer 

Parameter  for  calculation 

NotFireAt 

Integer 

Parameter  for  calculation 

DogFightBasic 

Integer 

Parameter  for  calculation 

KillRatioBad 

Integer 

Parameter  for  calculation 

KillRatioGood 

Integer 

Parameter  for  calculation 

MinWorstRatio 

Integer 

Parameter  for  calculation 

MinBstRatio 

Integer 

Parameter  for  calculation 

PercentRedDCA 

Integer 

Parameter  for  calculation 

PercentRedOCA 

Integer 

Parameter  for  calculation 

PercentRedFlying 

Integer 

Parameter  for  calculation 

MaxPercentRedAcftLost 

Integer 

Parameter  for  calculation 

RedAbort 

Integer 

Parameter  for  calculation 

RedFEBALoss 

Integer 

Parameter  for  calculation 

RedFtrLoss 

Integer 

Parameter  for  calculation 

RedTermLoss 

Integer 

Parameter  for  calculation 

RedNotFind 

Integer 

Parameter  for  calculation 

DoAndShowArmyMsns 

Integer 

Parameter  for  calculation 

ShowEnemyBmbrsOverBlueBases 

Integer 

Parameter  for  calculation 

TightenessFactor 

Integer 

Parameter  for  calculation 

AIMfudgeFactor 

Integer 

Parameter  for  calculation 
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Attribute 

Type 

Description 

PercentDailyDegradeGnd 

Integer 

Parameter  for  calculation 

AcftGndEquivFactor 

Integer 

Parameter  for  calculation 

GndDiffTomoveFEBA 

Integer 

Parameter  for  calculation 

Table  4.  Class  Employ-Attributes 


2/  Operations 


Operation 

Input 

Output 

initStudentServicesGUI 

None 

Student  (all  existed) 

initSelectATOGUI 

None 

ATODay  (all  existed) 

InitCopyATOGUI 

None 

ATODay  (all  existed) 

init20TgtHighestPriority 

None 

Targets  (all  existed, 
displays  the  first  20  with 
higher  priority) 

InitPlanEditMsns 

None 

m:  Mission  (all  existed) 

InitDeletePackage 

None 

p:  Integer 

SelectStudent 

SSN 

None 

AddStudent 

SSN,  rank,  firstName, 
lastName,  country, 
address,  e-Mail, 
section 

None 

getlntroReport 

None 

Report  (all  reports  existed) 

loadATODay 

SSN,  description,  day 

None 

AddATO 

SSN:  Text, 
description:  Text 

None 

selectATOToCopy 

SSN:  Text, 
description  1 :  Text, 
description2:  Text 

None 
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Operation 

Input 

Output 

eraseATO 

SSN:  Text, 
description:  Text 

None 

modifyTgt 

SSN:  Text 
description:  Text 
day:  Integer 
tgtNbr:  Integer 
priority:  Integer 

None 

enterMsn 

st:  Student, 
a:  ATO 
ad:  ATODay 
taskType:  Integer 
acftType:  Integer 
base:  Integer 
sector:  Integer 
tgtCategNbr:  Integer 
tgtSubNbr:  Integer 
bmbTypeNbr:  Integer 
nbrOfSorties:  Integer 
package:  Integer 

None 

deleteMsn 

SSN:  Text 
description:  Text 
day:  Integer 
msnNbr:  Integer 

None 

deletePackage 

SSN:  Text 
description:  Text 
day:  Integer 
package:  Integer 

None 

flyATO 

None 

None 

estimatedResults 

None 

r:  Report 
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Operation 

Input 

Output 

flightsWithoutSorties 

None 

r:  Report 

dailySummary 

None 

r:  Report 

logisticsRequirements 

None 

r:  Report 

blueBasingSum 

None 

r:  Report 

recceTgt 

None 

r:  Report 

analysis 

None 

r:  Report 

sortiesAvailable 

None 

r:  Report 

cumulativeSum 

None 

r:  Report 

enemyOverBlueBase 

None 

r:  Report 

groundWarS  ummary 

None 

r:  Report 

measuresOfMerit 

None 

r:  Report 

yesterdayLossesByAcft 

None 

r:  Report 

yesterdayLossesByTask 

None 

r:  Report 

selectMap 

mapNbr:  Integer 

map:  Map 

selectATOToSend 

SSN:  Text, 
description  1:  Text, 
description2:  Text 

None 

updateStudent 

st:  Student 
selection:  Boolean 

st:  Student 

addStudent 

st:  Student 

st:  Student 

updateReport 

r:  Report 

g:  GroundUnit:=Null 

None 

updateATODay 

ad:  ATODay 
selection:  Boolean 

None 

deleteATOday 

ad3:  ATODay 

None 

addGroup 

ad:  ATODay 

g:  Group 

None 

addSector 

ad:  ATODay 
s:  Sector 

None 
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Operation 

Input 

Output 

addTgt 

ad:  ATODay 
t:  Target 

None 

addMsn 

ad:  ATODay 

m:  Mission 

None 

checkMsn 

m:  Mission 

exist:  Boolean 

clacMsnLosses 

m:  Mission 

1:  Integer  Array 

updateMsn 

m:  Mission 
ad:  ATODay 
1:  Integer  Array 

None 

calculateEstimatedResults 

m:  Mission 

er:  Integer  Array 

updateReport 

r:  Report 

m:  Mission 

er:  Integer  Array 

None 

calcLogReq 

m:  Mission 

lr:  Integer  Array 

calculateAnalysis 

m:  Mission 

ana:  Integer  Array 

calculateSortiesAvailable 

m:  Mission 
g:  Group 

as:  Integer 

calculateCumSumP  1 

m:  Mission 

cs  1 :  Integer  Array 

calculateCumSumP2 

g:  Group 

cs2:  Integer  Array 

calculateCumSumP3 

t:  Target 

cs3:  Integer  Array 

calculateEnemyOverBlueBases 

b:  Base 
g:  Group 

eobb:  Integer 

calcSector 

m:  Mission 

si:  Integer 

calclateOverlndicators 

m:  Mission 
m:  Mission 

oi:  Integer  Array 

calculateLosses 

m:  Mission 
m:  Mission 

los:  Integer 

addStudent 

st:  Student 

None 
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Operation 

Input 

Output 

updateReport 

r:  Report 
gu:  Null 

None 

i 

Table  5.  Class  Employ-Operations 


Class  Student 


1/ 


Attributes 


Attribute 

Type 

Description 

SSN 

Text 

Unique  number  for  each  student 

Rank 

Text 

Rank  of  Student 

First  Name 

Text 

First  name  of  the  Student 

Last  Name 

Text 

Last  name  of  the  Student 

Country 

Text 

Country  of  the  Student 

Address 

Text 

Address  of  the  Student 

Section 

Integer 

Section  of  the  Student 

E-Mail 

Text 

E-mail 

Selection 

Boolean 

True  for  the  current  Student 

Table  6.  Class  Student-Attributes 


2/         Operations 


Operation 

Input 

Output 

getStudentAll 

None 

St:  Student 

getStudentSel 

selection  :  Boolean 

St:  Student 

getStudent 

SSN:  Text 

St:  Student 

checkStudent 

SSN:  Text 

Exist:  Boolean 

Table  7.  Class  Student-Operations 
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c. 


Class  ATO 


1/ 


Attributes 


Attribute 

Type 

Description 

Description 

Text 

The  ATO  name 

Selection 

Boolean 

True  for  the  current  ATO 

Table  8.  Class  ATO-Attributes 


2/  Operations 


Operation 

Input 

Output 

getATO 

st:  Student 

a:  ATO  (all  existed) 

addATO 

st:  Student 
description:  Text 

None 

getATO 

st:  Student 
description:  Text 

a:  ATO 

getATO 

st:  Student 
selection:  Boolean 

a:  ATO 

deleteATO 

st:  Student 
description:  Text 

None 

Table  9.  Class  ATO-Operations 


d. 


Class  ATODay 


1/ 


Attributes 


Attribute 

Type 

Description 

Day 

Integer 

The  ATODay  name 

Selection 

Boolean 

True  for  the  current  ATODay 

Table  10.  Class  ATODay-Attributes 
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2/  Operations 


Operation 

Input 

Output 

getATODay 

a:  ATO 

ad:  ATODAY 

getATODaySel 

selection:  Boolean 

ad:  ATODAY 

getATODayDay 

a:  ATO 

day:  Integer 

ad:  ATODAY 

addATODay 

a:  ATO 

day:  Integer 

None 

deleteATOdAY 

a:  ATO 
day:  Integer 

None 

getATODaySelandATO 

a:  ATO 
selection:  Boolean 

ad:  ATODAY 

Table  11.  Class  ATODay-Operations 


e. 


Class  Mission 


1/ 


Attributes 


Attribute 

Type 

Description 

MsnNbr 

Integer 

The  number  of  Mission 

Package 

Integer 

The  package  number  of  the 
Mission 

NbrOfSorties 

Integer 

The  number  of  sorties  assigned  in 
the  Mission 

Priority 

Integer 

The  priority  for  execution, 
describe  by  the  Task  Type  that 
assigned  to  the  Mission  and  by 
the  user  selection  in  20  highest 
priority  list 

SortieRate 

Integer 

Parameter  for  calculation 
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Attribute 

Type 

Description 

blueBombLoadQuantity 

Integer 

Parameter  for  calculation 

Table  12.  Class  Mission-Attributes 


2/         Operations 


Operation 

Input 

Output 

updateMsn 

taskType:  Integer 
acftType:  Integer 
base:  Integer 
sector:  Integer 
tgtNbr:  Integer 
tgtCaNbr:  Integer 
tgtSubNbr:  Integer 
bmbTypeNbr:  Integer 
nbrOfSorties:  Integer 
package:  Integer 

None 

deleteMsnAll 

ad:  ATODay 

None 

getMsnAll 

ad:  ATODay 

m:  Mission  (all  existed) 

getMsn 

ad:  ATODay 
msnNbr:  Integer 

m:  Mission 

addMsn 

taskType:  Integer 
acftType:  Integer 
base:  Integer 
sector:  Integer 
tgtNbr:  Integer 
tgtCaNbr:  Integer 
tgtSubNbr:  Integer 
bmbTypeNbr:  Integer 

None 

nbrOfSorties:  Integer 
package  Integer 
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Operation 

Input 

Output 

deleteMsn 

ad:ATODay 
msnNbr:  Integer 

None 

getMsnPkg 

ad:ATODay 

package:  Integer 

deleteMsnPkg 

ad:ATODay 
package:  Integer 

None 

deleteMsnBad 

ad:ATODay 

None 

updateSector 

ad:ATODay 
m.  sector:  Integer 
hlnteger 

None 

updateGroup 

ad:ATODay 
m.group:  Integer 
l:Integer 

None 

updateTarget 

ad:ATODay 
m.tgt:  Integer 
1:  Integer 

None 

Table  13.  Class  Mission-Operations 


/  Class  Target 


1/ 


Attributes 


Attribute 

Type 

Description 

TgtNbr 

Integer 

The  number  of  Target 

Name 

Text 

The  description  of  Target 

Zone 

Integer 

The  zone  of  Target 

Nationality 

Boolean 

True  for  the  Chinese  Targets, 
meaning  that  they  cannot  be 
assigned  to  a  Mission 

%Operational 

Integer 

The  percentage  operational  of  the 
Target 
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Attribute 

Type 

Description 



ShelterStatus 

Integer 

Parameter  for  calculation 

RisklnZone 

Integer 

Parameter  for  calculation 

RedBaseAcftTypeShetlerSatus 

Integer 

Parameter  for  calculation 

Table  14.  Class  Target-Attributes 


2/  Operations 


Operation 

Input 

Output 

deleteTgt 

ad:ATODay 

None 

getTgtAll 

ad:ATODay 

t:Target  (all  existed) 

updateTgt 

ad:ATODay 

tgtNbr:  Integer 
priority:Integer 

None 

Table  15.  Class  Target-Operations 


g.  Class  Category  (Target) 


Attributes 


Attribute 

Type 

Description 

Category  Nbr 

Integer 

Unique  number  for  every 
category 

Description 

Text 

The  description  of  Category 

RisklnZone 

Integer 

Parameter  for  calculation 

Table  16.  Class  Category-Attributes 


Class  Target  Subcategory 


Attributes 
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Attribute 

Type 

Description 

Subcategory  Nbr 

Integer 

Unique  number  for  every 
subcategory 

Description 

Text 

The  description  of  subcategory 

Table  17.  Class  Subcategory-Attributes 


Class  Group 


1/ 


Attributes 


Attribute 

Type 

Description 

GroupNbr 

Integer 

Unique  number  for  every  group 

AcftAvailable 

Integer 

Number  of  aircraft  available  in 
group 

Losses 

Integer 

Losses  of  group  from  the  start  of 
the  game 

Table  18.  Class  Group-Attributes 


2/  Operations 


Operation 

Input 

Output 

deleteGroup 

ad:ATODay 

None 

getGroup 

ad:ATODay 

g:  Group 

getGroupInit 

None 

g:Group 

Table  19.  Class  Group-Operations 


Class  Aircraft 


1/ 


Attributes 


Attribute 

Type 

Description 

AcftTypeNbr 

Integer 

Unique  number  for  every  aircraft 
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Attribute 

Type 

Description 

AcftName 

Text 

Description  of  aircraft 

InCommissionRate 

Integer 

Parameter  for  calculation 

AbortPercent 

Integer 

Parameter  for  calculation 

FuelPerSortie 

Integer 

Parameter  for  calculation 

AirAirAbility 

Integer 

Parameter  for  calculation 

AirToGroundAbility 

Integer 

Parameter  for  calculation 

Stealth 

Boolean 

True  for  aircrafts  without  losses 

Table  20.  Class  Aircraft-Attributes 


2/         Operations 


Operation 

Input 

Output 

getAcftType 

None 

acft:  Aircraft 

Table  21.  Class  Aircraft-Operations 


k. 


Class  Sector 


1/ 


Attributes 


Attribute 

Type 

Description 

SectorNbr 

Integer 

Unique  number  for  every  sector 

SectorName 

Text 

Description  of  sector 

BlueFrontLine 

Integer 

Parameter  for  calculation 

RedFrontLine 

Integer 

Parameter  for  calculation 

BlueReinfRate 

Integer 

Parameter  for  calculation 

RedReinfRate 

Integer 

Parameter  for  calculation 

CurFEBApsn 

Integer 

Parameter  for  calculation 

GroundResults 

Integer 

Parameter  for  calculation 

BluePosition 

Integer 

Parameter  for  calculation 
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Attribute 

Type 

Description 

RedPosition 

Integer 

Parameter  for  calculation 

Table  22.  Class  Sector-Attributes 


2/  Operations 


Operation 

Input 

Output 

deleteSector 

ad:  ATODay 

None 

getSectorlnit 

None 

s:  Sector 

getSector 

ad:  ATODay 

s:  Sector 

Table  23.  Class  Sector-Operations 


m.         Class  Task  Type 


1/ 


Attributes 


Attribute 

Type 

Description 

TaskTypeNbr 

Integer 

Unique  number  for  every  task 

TaskTypeName 

Text 

Description  of  task  type 
(abbreviation  of  ATO  type 
mission) 

FEBAlossBasic 

Integer 

Parameter  for  calculations 

FEBAlossIfDSA 

Integer 

Parameter  for  calculations 

FEBAlossIfDSUP 

Integer 

Parameter  for  calculations 

FEBAlossIfDSAandDSUP 

Integer 

Parameter  for  calculations 

DofFightProbBasic 

Integer 

Parameter  for  calculations 

DogFightProblfDSE 

Integer 

Parameter  for  calculations 

DogFightProbIfC3 

Integer 

Parameter  for  calculations 

DogfightProbIfDSEandC3 

Integer 

Parameter  for  calculations 
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Attribute 


Type 


Description 


TermLossBasic 


Integer 


Parameter  for  calculations 


TermLossIfO 


Integer 


Parameter  for  calculations 


TermLossIfDSA 


Integer 


Parameter  for  calculations 


TermLossIfDSUP 


Integer 


Parameter  for  calculations 


TermLossIfC3andDSA 


Integer 


Parameter  for  calculations 


TermLossIfC3andDSUP 


Integer 


Parameter  for  calculations 


TermLossIfDSAand  DSUP 


Integer 


Parameter  for  calculations 


TermLossIfC3andDSAandDSUP 


Integer 


Parameter  for  calculations 


ProbNotFind 


Integer 


Parameter  for  calculations 


Priority 


Integer 


Parameter  for  calculations 


Table  24.  Class  Task  Type—Attributes. 


2/  Operations 


Operation 

Input 

Output 

getTaskType 

None 

tsk:TaskType 

Table  25.  Class  Task  Type-Operations 


n.  Class  Bomb  Type 


Attributes 


Attribute 

Type 

Description 

BombTypeNbr 

Integer 

Unique  number  for  every  task 

bombTypeName 

Text 

Description  of  bomb  type 

Table  26.  Bomb  Type— Attributes 
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o.  Class  Map 


1/ 


Attributes 


Attribute 

Type 

Description 

MapNbr 

Integer 

Unique  number  for  every  map 

MapDescription 

Text 

Description  of  map 

Maplmage 

GIF 

Image  of  map 

Table  27.  Class  Map-Attributes 


2/  Operations 


Operation 

Input 

Output 

getMap 

None 

map:  Map 

getMap 

• 

mapNbr:  Integer 

map:  Map 

Table  28.  Class  Map-Operations 


Class  Report 


1/ 


Attributes 


Attribute 

Type 

Description 

ReportTitle 

Text 

Unique  number  for  every  report 

ReportBody 

Text 

Text  of  report 

Table  29.  Class  Report-Attributes 


2/         Operations 


Operation 

Input 

Output 

getlntroReport 

None 

r:  Report 

createReport 

title:  Text 

r:  Report 
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Operation 

Input 

Output 

createReport 

r:  ATODay 
title:  Text 

r:  Report 

Table  30.  Class  Report-Operations 
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V.   PROTOTYPE 

A.  PURPOSE 

The  purpose  of  this  chapter  is  to  describe  the  way  that  the  prototype  is 
implemented.  It  also  provides  a  "User  Manual"  of  the  prototype  for  easy  using. 

B.  PROTOTYPE  IMPLEMENTATION 

1.  General 

The  prototype  was  implemented  with  Microsoft  Access  2000  for  the  following 
two  reasons. 

First,  most  of  the  use  cases  can  be  implemented  as  interactions  between  the  GUI 
subsystem  and  the  Database  subsystem  without  involving  the  Application  subsystem. 

Second  the  number  of  functions  of  the  application  is  big  and  the  available  time  is 
not  enough  to  implement  the  Design  Specification  with  a  classical  object-oriented 
language. 

The  use  of  ACCESS  2000  cannot  fully  prove  the  object-oriented  Design 
Specification  of  Chapter  IV.  Yet  it  proves  the  correct  design  of  Database,  can  be  used  for 
the  verification  of  the  Requirements  Specification  of  Chapter  III,  and  partially  prove  the 
correctness  of  the  Objects'  attributes  and  interactions. 
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2.  Database  Design 

The  Prototype  consists  of  Tables,  Queries,  Forms,  Macros  and  Reports.  The 
Database  Entity-Relationship  Diagram  constructed  by  the  ER-Win  3.5  tool  of  "Logic 
Works"  is  displayed  in  Figure  12. 
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Figure  12.  Entity-Relation  Diagram  (Logic  Works  ER-Win  2.0  Database  Design 

Tool.) 

Entities  -  Relations  Attributes 


Relation  Name 

Attribute  Name 

Key 

Type 

1. 

STUDENT 

StudentSSN 

Primary 

Key 

(PK) 

Text 
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Relation  Name 

Attribute  Name 

Key 

Type 

StudentFirstName 

None 

Text 

StudentLastName 

Text 

RankAbbr 

Foreign 

Key 

(FK) 

Text 

StudentClassNbr 

Integer 

StudentSelection 

Yes/No 

StudentCountry 

Text 

2. 

ATOINFORMATION 

ATODescription 

Primary 

Text 

StudentSSN 

Primary 

Text 

3. 

ATODAY 

ATOExecutionTime 

Primary 

Integer 

ATODescription 

Primary 

Text 

StudentSSN 

Primary 

Text 

Selection 

Yes/No 

4. 

RANK 

RankAbbr 

Primary 

Text 

RankDescrption 

Text 

5. 

BLUEACFTTYPE 

BlueAcftTypeNbr 

PK 

Integer 

BlueAcftTypeName 

Text 

BlueAcftTypelnComPercent 

Integer 

BlueAcftTypeAbortPercent 

Integer 

BlueAcftTypeFuelPerSortie 

Integer 

BlueAcftTypeAirAirAbilityPercent 

Integer 

BlueAcftAirToGndCapab 

Integer 

BlueAcftAirToGndCapab 

Integer 

AcftFuel 

Text 
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Relation  Name 

Attribute  Name 

Key 

Type 

Stealth 

Yes/No 

6. 

BLUEBASE 

BlueBaseNbr 

PK 

Integer 

BlueBaseAbrreviation 

Text 

BlueBaseFullName 

Text 

BlueBasePercentOCA 

Double 

7. 

BLUEGROUP 

BlueBaseNbr 

PK-FK 

Integer 

BlueAcftTypeNbr 

PK-FK 

Integer 

BlueAcftAmmount 

Integer 

8. 

BLUEGROUPEXE 

ATOExecutionTime 

PK-FK 

Integer 

ATODescription 

PK-FK 

Text 

StudentSSN 

PK-FK 

Text 

BlueBaseNbr 

PK-FK 

Integer 

BlueAcftTypeNbr 

PK-FK 

Integer 

BlueAcftAmmount 

Integer 

9. 

BLUETASKTYPE 

BlueMissionTypeNbr 

PK 

Integer 

BlueMissionName 

Text 

FEBAlossBasic 

Double 

FEBAlossIfDSA 

Double 

FEBAlossIfDSUP 

Double 

FEBAlossIfDSAandDSUP 

Double 

DofFightProbBasic 

Double 

DogFightProblfDSE 

Double 

DogFightProbIfC3 

Double 

DogfightProbIfDSEandC3 

Double 

TermLossBasic 

Double 
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Relation  Name 

Attribute  Name 

Key 

Type 

TermLossIfC3 

Double 

TermLossIfDSA 

Double 

TermLossIfDSUP 

Double 

TermLossIfC3andDSA 

Double 

TermLossIfC3andDSUP 

Double 

TermLossIfDSAand  DSUP 

Double 

TermLossIfOandDSAandDSUP 

Double 

ProbNotFind 

Double 

Priority 

Integer 

10.        BLUEBOMBTYPE 

BlueBombTypesNbr 

PK 

Integer 

BlueBombTypeName 

Text 

11. 

BLUEPROPERACFTPERMISSION 

BlueAcftTypeNbr 

PK-FK 

Integer 

BlueMissionTypeNbr 

PK-FK 

Integer 

BlueProperAcftTypePerMissionNbr 

Integer 

12. 

BLUEBOMBSPERACFTMSNTYPE 

BlueAcftTypeNbr 

PK-FK 

Integer 

BlueMissionTypeNbr 

PK-FK 

Integer 

BlueBombNbrPerAcftMsnBomb 

Integer 

13. 

BLUESORTIESRATEBYMSNACFT 

BlueAcftTypeNbr 

PK-FK 

Integer 

BlueMissionTypeNbr 

PK-FK 

Integer 

BlueMsnAcftTypeRate 

Integer 

14. 

BLUEACFTTYPEBOMBLOADANDDISTANCE 

BlueSpCharacteristicNbr 

PK 

Integer 

BlueBombTypesNbr 

PK-FK 

Integer 

BlueBombLoadAmmount 

Integer 

BlueRangeWithLoad 

Integer 
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Relation  Name 

Attribute  Name 

Key 

Type 

15. 

BLUECASBOMBLOAD 

BlueAcftTypeNbr 

PK-FK 

Integer 

BlueBombTypesNbr 

PK-FK 

Integer 

BlueBombLoadQuantity 

Integer 

16. 

BLUEWEASELACFTYPEBOMB 

BlueAcftTypeNbr 

PK-FK 

Integer 

BlueBombTypesNbr 

PK-FK 

Integer 

17. 

BLUEMISSIONSPECCHARACTTYPES 

BlueSpCharacteristicNbr 

PK 

Integer 

BlueSpCharacteristicDescriptionr 

Integer 

18. 

BLUEMISSIONCHARACTERISTICS 

BlueSpCharacteristicNbr 

PK-FK 

Integer 

BlueAcftTypeNbr 

PK-FK 

Integer 

BlueMissionTypeNbr 

PK-FK 

Integer 

19. 

SECTOR 

SectorNbr 

PK 

Integer 

SectorName 

Text 

SectorBlueCASPercntNeed 

Double 

SectorBlueSAPercentNeed 

Double 

SectorBlueReccePercentNeed 

Integer 

SectorBlueFrontLine 

Integer 

SectorBlueReinforce 

Integer 

SectorRedFrontLine 

Integer 

SectorRedReinforce 

Integer 

20. 

SECTOREXE 

SectorNbr 

PK-FK 

Integer 

ATOExecutionTime 

PK-FK 

Integer 

ATODescription 

PK-FK 

Text 

StudentSSN 

PK-FK 

Text 
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Relation  Name 

Attribute  Name 

Key 

Type 

CurrentFEBAPosition 

Integer 

GndResults 

Integer 

BluePosition 

Integer 

RedPosition 

Integer 

TotalFEBA 

Integer 

21. 

REDTARGET 

i 

RedTargetNbr 

PK 

Integer 

RedTargetDescription 

Text 

ZoneNbr 

FK 

Integer 

RedTargetLatidute 

Double 

RedTargetLongidute 

Double 

RedTargetChinese 

Yes/No 

22. 

REDTARGETZONE 

ZoneNbr 

PK 

Integer 

RisklnZone 

Integer 

23. 

REDMISSIONTYPE 

RedMissionTypeNbr 

PK 

Integer 

RedMissionDescription 

Text 

24. 

REDTARGETCATEGORY 

TargetCategoryNbr 

PK 

Integer 

TargetCategoryDesc 

Text 

25. 

REDTARGETSUBCATEGORY 

Targets  ubCategNumber 

PK 

Integer 

TargetCategoryNbr 

PK-FK 

Integer 

TargetSubCategDescr 

Text 

TargetSubCategRebRate 

Double 

Targets  ubCategRebTimes 

Integer 

26. 

REDTARGETCATEGORYSUBCATEGORY 
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Relation  Name 

Attribute  Name 

Key 

Type 

Targets  ubCategNumber 

PK-FK 

Integer 

TargetCategoryNbr 

PK-FK 

Integer 

RedTargetNbr 

PK-FK 

Integer 

27. 

REDTARGETOPERATIONAL 

TargetCategoryNbr 

PK-FK 

Integer 

RedTargetNbr 

PK-FK 

Integer 

ReccePercentOperational 

Integer 

MaxPercentOperational 

Integer 

28. 

REDTARGETOPERATIONALEXE 

ATOExecutionTime 

PK-FK 

Integer 

ATODescription 

PK-FK 

Text 

StudentSSN 

PK-FK 

Text 

TargetCategoryNbr 

PK-FK 

Integer 

RedTargetNbr 

PK-FK 

Integer 

ReccePercentOperational 

Integer 

MaxPercentOperational 

Integer 

29. 

REDBASE 

RedBaseNbr 

PK 

Integer 

RedBaseDescription 

Text 

30. 

REDACFTTYPE 

RedAcftTypes 

PK 

Integer 

RedAcftDescription 

Text 

31 

REDGROUP 

RedAcftTypes 

PK-FK 

Integer 

RedBaseNbr 

PK-FK 

Integer 

RedMissionTypeNbr 

FK 

Integer 

RedGroupNbr 

Integer 

RedAcftNumber 

Integer 
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Relation  Name 

Attribute  Name 

Key 

Type 

RedMissionTypeSortyRate 

Integer 

32 

REDGROUPEXE 

ATOExecutionTime 

PK-FK 

Integer 

ATODescription 

PK-FK 

Text 

StudentSSN 

PK-FK 

Text 

RedAcftTypes 

PK-FK 

Integer 

RedBaseNbr 

PK-FK 

Integer 

RedAcftNumber 

Integer 

RedLosses 

Integer 

33. 

REDSHELTERSTAT1 

US 

ShetlerStatusNbr 

PK 

Integer 

ShetlerDescription 

Text 

34. 

REDBASEACFTTYP] 

ESHELTERSTATUS 

RedAcftTypes 

PK-FK 

Integer 

RedBaseNbr 

PK-FK 

Integer 

ShetlerStatusNbr 

FK 

Integer 

35. 

EMPTY20HIGHESTPRIORITYLIST 

Priority 

PK 

Integer 

RedTargetNbr 

FK 

Integer 

36. 

REDTARGET20HIGHESTPRIOTIYLISTEXE 

Priority 

PK-FK 

Integer 

ATOExecutionTime 

PK-FK 

Integer 

ATODescription 

PK-FK 

Text 

StudentSSN 

PK-FK 

Text 

RedTargetNbr 

FK 

Integer 

37. 

REDBASECATEGORYDIFIICULTY 

RedBaseNbr 

PK-FK 

Integer 

TargetCategoryNbr 

PK-FK 

Integer 

TargetSubCategNumber 

PK-FK 

Integer 
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Relation  Name 

Attribute  Name 

Key 

Type 

38. 

RECCETGTPSN 

ATOExecutionTime 

PK-FK 

Integer 

ATODescription 

PK-FK 

Text 

StudentSSN 

PK-FK 

Text 

RedTargetNbr 

PK-FK 

Integer 

FlightNbr 

PK-FK 

Integer 

39. 

FLIGHTDATA 

ATOExecutionTime 

PK-FK 

Integer 

ATODescription 

PK-FK 

Text 

StudentSSN 

PK-FK 

Text 

FlightNbr 

PK 

Integer 

BlueBaseNbr 

FK 

Integer 

BlueAcftTypeNbr 

FK 

Integer 

BlueMissionTypeNbr 

FK 

Integer 

SectorNbr 

FK 

Integer 

TargetSubCategNumber 

FK 

Integer 

TargetCategoryNbr 

FK 

Integer 

RedTargetNbr 

FK 

Integer 

BlueBombTypesNbr 

FK 

Integer 

FlightBlueSortiesAssigned 

Integer 

MssnPkgNbr 

Integer 

40. 

BLUESORTIE0_7AC] 

FTBOMBTGTATSUB 

TargetCategoryNbr 

PK-FK 

Integer 

TargetSubCategNumber 

PK-FK 

Integer 

BlueAcftTypeNbr 

PK-FK 

Integer 

BlueBombTypesNbr 

PK-FK 

Integer 

BlueSortieO_7 

Integer 

41. 

BLUEPRIMARYUNIT 

PrimeUTC 

PK 

Text 
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Relation  Name 

Attribute  Name 

Key 

Type 

PrimellnitName 

Text 

PrimeUnitAmmunition 

Integer 

42. 

DEPLOYDATA 

PrimeUTC 

PK-FK 

Text 

ArmyDivs 

Integer 

Nbr2 

Integer 

Nbr3 

Integer 

Nbr4 

Integer 

43.        REPORT 

Reportid 

PK 

Integer 

ReportLabel 

Text 

ReportText 

OLE 

Object 

44. 

PARAMETERS 

Hi_5  Damage 

Integer 

Lo_5Damage 

Integer 

Hi_7Damage 

Integer 

Lo_7Damage 

Integer 

NotFireAt 

Integer 

DogFightBasicLoss 

Integer 

KillRatioBad 

Integer 

KillRatioEven 

Integer 

KillRatioGood 

Integer 

MinWorstRatio 

Integer 

MinBestRatio 

Integer 

PercentRedDCA 

Integer 

PercentRedOCA 

Integer 

PercentRedFlying 

Integer 

MaxPercentRedAcftLost 

Integer 
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Relation  Name 

Attribute  Name 

Key 

Type 

RedAbort 

Integer 

RedFEBALoss 

Integer 

RedFtrLoss 

Integer 

RedTernLoss 

Integer 

RedNotFind 

Integer 

Do  AndS  how  Army  Missions 

Integer 

ShowEnemyBpmbersOverBlueBases 

Integer 

TightnessFactor 

Integer 

AIMfudgeFactor 

Integer 

PercentDailyDegradeGnd 

Integer 

AcftGndEquivFactor 

Integer 

GndDiffToMoveFEBA 

Integer 

TopLat 

Integer 

BottomLat 

Integer 

LeftLong 

Integer 

RightLong 

Integer 

Table  31.  Entities  -  Relations  Attributes. 

The  Database  Entity-Relation  Diagram  of  Figure  12  and  the  Relations' description 
of  the  table  above  can  also  be  used  as  Database  design  for  the  implementation  of  the  final 
Application.  The  prototype's  database  contains  some  extra  relations  that  are  used  for  the 
calculations  only  and  should  not  be  included  in  the  final  application  database.  This  kind 
of  relation  has  the  prefix  "TMP"  for  easy  recognition  from  the  main  relations  of  the 
database. 
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The  prototype  was  a  combination  of  ACCESS  2000  Forms,  Visual  Basic  code, 
queries,  and  macros  to  provide  user  friendly  GUI.  The  GUI  design  and  probably  the 
implementation  can  be  used  for  the  final  application. 

The  queries  are  written  by  the  special  ACCESS  2000  SQL.  In  the  case  when  a 
query  is  very  complicated  to  be  executed,  nested  queries  that  construct  temporary  tables 
are  used.  The  use  of  nested  queries  reduces  the  prototype's  performance  because  of  its 
extensive  use  of  the  storage  devices,  which  are  the  slowest  components  of  a  computer. 
On  the  other  hand,  it  offers  the  functionality  that  the  prototype  needs. 

Macros  are  used  mainly  for  two  reasons  to  create  a  sequence  of  events  (queries) 
and  to  offer  runtime  information  to  the  GUI. 

Reports  are  used  only  for  printing  necessities  and  they  are  the  printable  versions 
of  GUIs  (Forms.) 

C.         USER  MANUAL 

1.  Installing  CAMPEX  Employment  Module  Prototype 

•  Recommended  System:  IBM  PC-compatible  486  computer  running 
Microsoft  WINDOWS  (NT  3.5  or  98)  or  higher,  with  minimum  16  MB 
RAM  and  minimum  256-color  monitor. 

•  Copy  the  file  CAMPEX2000.mdb  from  its  source  to  desktop  (a  shortcut  is 
created.)  The  size  of  the  prototype  is  expected  to  be  10  MB  when  it  needs 
ACCESS  2000  to  run  (current  version)  and  above  25  MB  if  it  can  run  as 
an  independent  application. 
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2.  Running  the  CAMPEX  Employment  Module  Prototype 

•  Double  click  on  the  application  icon  and  the  program  starts  to  execute. 

•  In  every  screen  student  has  the  choices  "Return"  and  "Exit."  With 
"Return, "  the  system  returns  to  previous  screen,  and  with  "Exit, "  the 
system  quits  the  application. 


Figure  13.  Return  and  Exit 

3.  CAMPEX  Employment  Module  Initial  Screen 

The  Initial  screen  of  CAMPEX  Employment  Module  appears  with  one  menu  bar 
on  the  top  of  the  screen  named  "Student",  with  three  choices: 

•  "New  Student"  must  be  selected  if  the  student  executes  the  program  for 
first  time. 

•  "Select  Student",  must  be  selected  if  student  has  already  input  his  personal 
information  in  the  program. 

•  "Exit"  to  quit  the  application. 
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Figure  14.  Initial  Screen 

4.  "New  Student" 

•  An  empty  "Student"  record  is  displayed. 

•  Enter  the  necessary  student  information. 

•  Fill  all  data  fields. 

•  Select  return. 
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IS  Student 


y  say  *%iM^<|:iHi!^lv  H:m*  §§  ©%*,© 


Figure  15.  New  Student 


"Select  Student  " 


System  returns  a  list  of  student  names. 


•     Select  a  name  from  the  list. 


•     Select  "Continue." 
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CONTINUE 


RETURN 


Figure  16.  Select  Student 


6. 


'Start  Employment  Module" 


;E3  student^ _____ 


IVe  suggest  you  to  wevif  the  Program  Report*  art  teas*  ffre  first  fime  you  rim  this  program  (some  may 
contain  critical  information.)  You  may  also  view  them  later  by  using  the  "Options"  menu  off  main 


Click  to  see  the  Program  Reports 


Click  to  continue  with  program 


RETURN 


Figure  17.  Choose  to  see  Reports  or  Not 

"Click  to  See  the  program  Reports"  must  be  selected  if  the  student  wants 
to  see  the  "Introductory  Reports." 
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"Click  to  Continue  with  Program"  must  be  selected  if  the  user  wants  to 
continue  with  the  program  without  seeing  the  "Introductory  Reports." 


7.  "Click  to  See  the  Program  Reports" 

A  screen  with  the  first  Introductory  Report  will  be  displayed.  Student  can  see  the 
report  by  using  the  right  screen  scrollbar,  by  clicking  inside  the  report  and  by  using  the 
keyboard  up  and  down  arrows.  Notice  that  the  student  has  seen  the  whole  report  only  if 
he  is  able  to  see  the  note  "Last  Line,"  written  with  red  letters. 
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Weather  Report 
Dateline  31  Mar  97 

High  altitude  cloud  cover  Is  expected  over  the  area  of  operations  for  the  next  three  weeks. 
Satellite  recce  sources  will  be  of  minimum  use  dunng  this  time 
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Figure  18.  Introductory  Report 

Select  (►)  to  continue  with  the  next  "Introductory  Report." 
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8.  "Click  to  Continue  with  Program" 

A  screen  with  the  "Ground  Combat  Units  as  of  Day  1 "  will  be  displayed.  This 
report  is  always  empty,  because  the  information  it  contains  is  a  product  of  "CAMPEX 
Deployment  Module"  that  has  not  yet  been  implemented. 


student 


GROUND  COMBAT  UNITS  AS  OF  DAY  1 


Prime  UTC 


Unit  Name/DescriDtion 


MEBHS 


MEFGE 


jlArmored  Divj 


Sep  Armored  Bde 


MEBGndCbtElem 


|MEF  Gnd  Cbt  Elem 


Air  Assault  Div 


lYrJffl  > 


Antonios  Hal 


CONTIINUE     RETURN  EXIT 


Figure  19.  Ground  Combat  Units 

Select  "Continue." 


9.  "ATO  Selection" 

•  "Select  an  ATO"  must  be  selected  if  the  student  wants  to  execute  an 
existing  ATO. 

•  "If  the  ATO  is  not  on  the  list  Click  the  Button  to  Enter"  must  be  selected  if 
the  user  wants  to  enter  an  ATO  that  is  not  existed  in  the  list. 
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10.        "Select  an  ATO" 

•  Select  an  ATO  description. 

•  Select  an  ATO  day. 


Figure  20.  ATO  Selection 

If  the  student  selects  an  ATO  day,  all  the  days  following  the  selected  day  and  their 
information  will  be  deleted. 

11.        "New  ATO  " 

An  empty  ATO  record  is  displayed,  if  the  student  selects  "If  the  ATO  is  not  on  the 
list  click  the  Button  to  Enter". 
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ATO  INFORMATION 


Enter  new  ATO  Name; 


RETURN 


Figure  21.  Enter  a  New  ATO 

•  Enter  the  necessary  information. 

•  Select  "Return". 

Program  returns  to  the  previous  screen  and  user  must  select  an  ATO  to  continue. 

12.        "Main  Menu  Screen" 

On  the  top  of  the  screen  a  new  "Menu  Bar"  will  be  displayed  with  three 
choices: 

•  "Options." 

•  "ATO  Planning." 

•  "Intel  and  Results." 
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EI    Student  Options  |  ATO  Planning  Site!  and  Resufe 


^i*j_> 


CAMPEX  MAIN  MENU 


Figure  22.  Main  Menu 

13.        "Options" 

•  "Open  Introductory  Report"  must  be  selected  to  see  an  Introductory 
Report. 

•  "Area  Map"  must  be  selected  to  see  the  Area  Map. 

•  "Change  ATO"  must  be  selected  to  return  to  the  state  of  selecting  an  ATO. 

•  "Blue  Basing  Summary"   must  be   selected  to   see   the  blue   "Basing 
Summary"  report. 

•  "Sorties  Available"  must  be  selected  to  see  the  blue  "Sorties  Available" 
report. 

•  "Analysis"  must  be  selected  to  see  the  blue  "Analysis"  report. 
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Area  Map 
Change  ATO 
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Analysis 
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CAMPEX  MAIN  MENU 


Ml 


Figure  23.  Options  Menu 

14.        "Open  Intro  Report" 

System  returns  a  list  with  all  Introductory  Reports' Titles. 

•  "Select  a  title  from  the  list."  The  selected  Report  will  be  displayed, 
pressing  the  "Return"  button  will  return  to  the  "Report  Management 
Screen." 


101 


Figure  24.  Report  Management 


15.        "Area  Map  " 


Figure  25.  Area  Map 


102 


16.  "Change  ATO" 

"ATO  Selection"  screen  will  be  displayed.  User  must  follow  the  same  known 

sequence  as  in  the  section  4.D.1 1. 

17.  "Blue  Basing  Summary  " 
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Figure  26.  Blue  Basing  Summary 


18.        "Sorties  Available  " 


Figure  27.  Sorties  Available 
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19. 


'Analysis 


None  Scheduled 
None  Scheduled 
None  Scheduled 
None  Scheduled 
None  Scheduled 


None  Scheduled 


EXIT        RETURN 


,    Ms  Comment 
insufficient  area  suppression  with  zones: 

Target  Zone:  1 

Target  Zone:  4 

Target  Zone:  7 


Figure  28.  Analysis 


20.        "ATO  Planning" 


Student  Opsone  jj  ATO  Planning  Intel  and  ftest&B 


*\B'-&Q>y        20T"P  PrJorrtyTargets 
Plan  Ed«  MtEtont 
Estimated  Resute 
Flights  Without  Sorbes 
DaHy  Summaries 
Cancel  Mission  Or  Package 
Logistics  Reejjremerifis 
FtyATOMtesfans 
Ground  Forces  Deployed 


*?.mw 


M  *  I  cS»   ©  ta  •  I  Q  . 


/IPEX  MAIN  MENU 


,,.,151  > 


Figure  29.  Menu  "ATO  Planning" 
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•  "20  Top  Priority  Targets"  must  be  selected  to  describe  the  20  targets  with 
highest  priority. 

•  "Plan  Edit  Missions"  must  be  selected  to  plan  missions  for  an  ATO. 

•  "Estimated  Results"  must  be  selected  to  see  the  "Estimated  Results"  report 
of  his  planning. 

•  "Flights  Without  Sorties"  must  be  selected  to  see  the  "Flights  Without 
Sorties  "  report. 

•  "Daily  Summaries"  must  be  selected  to  see  the  "Daily  Summaries  "  report. 

•  "Cancel  Mission  or  Package"  must  be  selected  to  delete  a  planned  mission 
or  package  of  missions. 

•  "Logistic    Requirements"     must    be    selected    to    see    the     "Logistic 
Requirements  "  report. 

•  "Fly  ATO  Missions"  must  be  selected  to  execute  the  planned  ATO. 
System  changes  state  to  the  next  ATO  day. 

•  "Ground  Forces  Deployed"  must  be  selected  to  see  the  "Ground  Forces 
Deployed  "  report. 
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21. 


'20  Top  Priority  Targets  " 


LIST  OF  20TARGETS  WITH  HIGHE 

•ST  PRIORITY 

Odyseas 1 

j  Red  Target  Priorilty  J 

Selects  Target 

— -    I 

1 

15ilB 

2 

a«fe 

7 

Mengzi  Airbase 

5 

8 

9 

10 

11 

12 

13 

14 

Bai  Thuong  Airbase 
Pleiku  Airbase 
Cam  Ranh  Airbase 
Kep  Airbase 
Haiphong/Kien  Airbase 
Phu  Cat  Airbase 
Tuy  Hoa  Airbase 

4 

5 

6 

7 

8 

'JMjjB 

9 

5ill  J 

10 

6bB 

11 

Wp 

12 

.H 

n                                                                                  " ~»H 

D 

1  ffifrl 

RETURN 

EXIT 

Figure  30.  List  of  20  Targets  with  Highest  Priority 

Select  the  priority  number,  and  then  select  a  Target  from  the  list.  The  user 
cannot  select  the  same  target  more  than  once  in  a  Priority  List. 


22.        "Plan  Edit  Missions  " 


"Aircraft  Type. 


•     "Blue  Base." 


"Red  Base  or  Target  Number." 


106 


"Target  Type." 
"Zone  of  Target." 
"Task  Type." 
"Packages." 
"List  All." 


FU< 

Aircraft  Type : 

Blue  Base: 

Red  Base  or  Target  Number : 

Target  Type : 

Zone  of  Target: 

Task  Type : 

Packages : 

List  All: 

Major 
AntoniosHal 

3HTS  CATEG 

QRIES 

PI 

Odyseasl 

prop] 
EXIT 

1 

I  OA-10 

i  FA-18 
i AC 130 

■  F-15E 

■  WW 
If-15 
I  F-16 

■  F111 

I 
I 

I 

1 

-Lj! 

a 

H 

RETURN 

Figure  31.  Flight  Categories 

Only  the  Flights  in  the  planned  missions  will  be  displayed.  Selecting  the  "List 
All"  option  will  results  in  the  display  shown  in  Figure  32.  The  user  can  see  the  planned 
missions  up  to  that  moment  now  by  the  selected  choice. 

Select  "To  Enter  a  new  Flight  or  to  edit  an  existing  click  the  button  below"  to 
modify  flights. 
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Flight     Mission  Type 

;  Aircraft  Type  Blue  Bass  Abrreviation           Blue  Base  Name 

Sector  Number  Tgt  Nbr  Target  Descnptio I 

OOCA 

F-16 

TUU 

Ufaon 

0 

9 

Pleiku  Airbase 

2 

CAS 

FA-18 

TUN 

Korat 

2 

0 

3 

CAS 

F-16 

TUU 

Ubon 

3 

0 

4 

EW 

EA-6 

TUN 

Korat 

0 

0 

6 

CAS 

OA-10 

TNP 

Nam  Phong 

1 

0 

Figure  32.  Assigned  Flights  By  Category 

23.        *  'Enter  or  Edit  Flight ' ' 

•  "To  Enter  a  new  Flight  Enter  the  Flight  Number  and  click  on  the  Button 
below"  must  be  selected  to  enter  a  new  Mission. 

•  "The  numbers  in  the  list  already  exist  so  you  cannot  enter  them  but  you 
can  edit  them"  must  be  selected  to  edit  a  mission. 

•  Select  an  existed  flight  number  or  enter  a  new  number  will  result  in  the 


display  shown  in  Figure  34. 
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ENTER  OR  EDIT  A  FLIGHT 

To  Enter  a  new  Flight  Eater  the  Flight               The  numbers  in  the  list  already  exisi  so  you 
Number  and  click  on  the  Button  below                cannot  enter  them  but  you  can  edit  them 

H 

©1 

RETURN 

Em 

Figure  33.  Enter  or  Edit  a  Flight 

24.  "Flight  Data  " 

•  Enter  the  necessary  flight  information. 

•  Fill  all  data  fields. 

•  Select  "Return." 
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FLIGHT  DATA 


Flight  Number: 

Mission  or  Task: 

Supported  Sector: 


Target  Category: 

Target  Clearance: 

Target  SAY: 

Aircraft  type: 

Blue  Base: 

Bomb  Load  Type: 

Bomb  Quantity: 

Mission  Package: 

Target  Zone: 


6 
0 
i 


For  frje  Selected  Mission  Fype  you  cannot  assign  s  Sen 
For  #?e  SefeeJes?  Mission  Type  you  cannot  assign  a  Ts; 


Select  four  targets  Only  for  Recce 

For  the  Selected  Miss  fan  Type  you  cannot  assigns  . « 


For  every  Mission  you  have  toseiect  an  Aircraft  Typt 

-^ir  w«/ar»  Mi&Kiiriri  \iriti  haw**  frt  c*»&»^*f  £t  Rf.t*&  o™^« 


Figure  34.  Input  or  Update  Flight  Data 


25.        "Estimated  Results  Choices" 

"Aircraft  Type." 

"Blue  Base." 

"Red  Base  or  Target  Number." 

"Target  Type." 

"Zone  of  Target." 

"Task  Type." 

"Packages." 

"All  Flights." 
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Stutter*  Options   JATORIarmUg  Intel  aid  Results 
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Estimated  Results 


.»)»!» 


'y  %  n'"  M 1  »*  *jt§,iet-'a»|gl 


►  I       Aircraft  Type 


RHghts  Without  Sorties 
Daily  Summaries 
Cancel  Mission  Or  Package 
Lojffixt  Roqu«- errant* 
Rly  ATO  Missions 
Ground  FOTCB*  DBptoyod 


RetSaseQr  Target 
Target  Category 
TergetZone 
T39fcT)fpB 
Mtwwn  Package 
AH  Rights 


OA-iO 

R-18 

AC-130 

F-1SE 

WW 

R-I5 

F-I6 

js-iil 

9F-X11 

R-U7 

B-52 

A-6 


MENU 


Figure  35.  Estimated  Results  Choices 

Each  of  these  choices  leads  to  another  menu  of  choices  that 
describes  a  filter  for  the  way  that  the  user  can  see  the  "Estimated  Results"  report. 


26.        "Estimated  Results" 


Mission  I    Task      Aircraft 
Number!    Type        Type 


ESTIMATED  RESULTS  FOR  Odyseasl 


I  Target     Target  [Target  [Target    Target    Mission  I     ' 
Number    Type  |    CIS   1    AA    J  Zone    Package!      i 


Figure  36.  Estimated  Results 
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27.        "Flights  without  Sorties" 


FLIGHTS  WITHOUT  SORTIES 


Odyseas 


Flight    I  Aircraft    !    Mjssson 
Number       TVs*     *      Tyne 


I  Blue  Base 
Abrrevrationl 


Blue  Base  Name 


Msrifstoors  ;..,.._       Targe 
:      Catenc 


«  M5E.  OCA  HP! 


fMengzt  Airbase 


7  Mengzi  Aifbase 


6  PA-18  OCA  ICVN 


7 WWigtl  Atrbase 


6FA-18  OCA  ICVN 


7  Mengil  Airbaie 


Figure  37.  Flights  without  Sorties 


28.        "Daily  Summaries  " 


PLANNED  SORTIES  BY  MISSION  TASK  TYPE  FOR  DAY 
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RETURN 


Figure  38.  Daily  Summary 
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29.        "Cancel  Mission  or  Package" 


CANCEL  MISSIONS  OR  TiHISSJONS  PACKAGES 


?rf!S»iori    las?.  I  Gtouno    I  fa* get  I 
iHumfcer  Type  ls«pp#it«>3JNumbcr I 


Type     CIS     SAM     type 


Type  I  Zone  \P 


EE3| 


PekuAirbase         Acft      Rev     SA3    F 16 


E3EEZ3 


1 33 1 


HEBSE3EIEI35 


'fTIJ 


IE2EL1 


A-1C       Nam  Phong 


E3j 


1       I  CAS  |  Scciotf 


-A-18  Koral 


Select  a  Mission  to  Cancel 


Select  a  Package  to  Cancel  the  Missions 


RETURN 


Figure  39.  Cancel  Mission  or  Missions'  Package 

•  "Select  a  Mission  to  Cancel." 

•  "Select  a  Package  to  Cancel  the  Missions." 

System  returns  a  List  of  the  planned  missions  or  packages  (depending  on  the 
user's  choice.) 

Select  a  Mission  or  Package  Number.  The  system  deletes  the  selected  mission  or 
the  missions  of  the  selected  package. 
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30.        "Logistic  Requirements  " 


LOGISTICS  NEED  TO  FLY  DAY 


Odyseas ' 


Blue  Base  Name  1  PM   \  M.N28    MW2  ■!  mm     mm  jMklffD   C8U    CBU-52    GBU      May    ASM45  FueIC 


Figure  40.  Logistics  Requirements 

31.  "Fly  ATO  Missions" 

System  executes  mission  and  changes  state  to  the  next  day. 

32.  ' '  Ground  Forces  Deployed ' ' 

As  shown  Figure  1 8 
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33.        "Intel  and  Results'* 


Student  Options  ;  ATO  Pfenning  lintel  and  ReaSs 


,\8i> 


Current  Recce 
6nemy  Oner  8ije  Bases 
Ground  war  Summary 
view  Measures  of  Merit 
Vfcfiterday's  tossesSy  Task  Type 
Yesterday's  Losses  By  Acft  Type 


*:S'|©ve''l*>J 


MAIN  MENU 


Figure  41.  Menu  Intel  Results 

They  are  active  only  if  the  user  has  executed  a  planning  (Fly  an  ATO): 

•  "Sorties  Effect"  must  be  selected  to  see  the  "Sorties  Effect"  report  of  his 
planning. 

•  "Current  Recce"  must  be  selected  to  see  the  "Current  Recce"  report  of  his 
planning. 

•  "Enemy  Over  Blue  Bases"  must  be  selected  to  see  the  "Enemy  Over  Blue 
Bases"  report  of  his  planning. 

•  "Ground  War  Summary"   must  be   selected  to   see  the   "Ground  War 
Summary"  report. 

•  "View  Measures  of  Merit"  must  be  selected  to  see  the  "View  Measures  of 


Merit"  report. 
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•  "Yesterday  Losses  by  Task  Type"  must  be  selected  to  see  the  "Yesterday 
Losses  by  Task  Type"  report. 

•  "Yesterday  Losses  by  Acft  Type"  must  be  selected  to  see  the  "Yesterday 
Losses  by  Aircraft  Type"  report. 

Depending  on  the  user's  choice,  the  selected  report  will  be  displayed.  In  addition, 
user  can  choose  to  print  the  report. 


Weight  of  Effort  By  Army-Recce- 
Other 


Blue  Attrition  Percent 

A 


0.5 


.A 


Figure  42.  Sample  Intel  Report  "Measures  of  Merit" 
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VI.   CONCLUSIONS 

This  thesis  examined  three  distributed  component  architectures:  Microsoft's 
DCOM,  Sun  Microsystems 's  JINI,  and  the  OMG's  CORBA,  and  concluded  that  they 
have  similar  capabilities,  but  each  has  distinct  strengths  and  weaknesses.  CORBA  seems 
to  be  the  best  solution  for  using  legacy  applications  as  components  because  of  its  ability 
to  cross  languages  boundaries.  In  practice,  however,  most  old  applications  cannot  be  used 
as  components  because  they  are  not  implemented  using  object-oriented  technology.  Thus, 
it  is  necessary  to  redesigned  and  re-implement  the  legacy  applications  using  object- 
oriented  technology  before  they  can  be  used  as  distributed  components.  In  this  case,  JINI 
in  combination  with  the  Java  programming  language  comprises  the  most  complete 
solution.  JINI  implementations  are  fully  compatible  to  each  other  and  Java  supports 
extensive  object-oriented  design  and  implementation. 

The  analysis  and  redesign  of  CAMPEX  proved  the  concept  that  old  applications 
are  not  useless.  The  old  version  of  CAMPEX  was  the  main  source  for  the  Requirements 
Analysis  and  Design  Specification.  The  Requirements  Analysis  was  a  product  of  reverse 
engineering  the  old  CAMPEX  functionality  and  much  of  the  detailed  design  are  resulted 
from  reverse  engineering  the  CAMPEX  source  code.  The  process  of  reverse  engineering 
was  not  cost  free.  It  required  more  time  and  added  difficulties  and  risks  to  the  whole 
process. 

Using  the  Unified  Modeling  Language  (UML)  for  the  analysis  and  the  design  of  a 

software  product  adds  risk  to  the  development  process  when  the  designer  is  not 

experienced  in  using  the  language.  The  primary  advantage  of  the  UML  Methodology  is 

that  the  processes  overlap  each  other,  thus  the  designer  gain  a  more  complete  knowledge 

117 


for  the  whole  problem.  On  the  other  hand  the  overlap  in  the  UML  process  consumes 
additional  time.  Moreover  the  design  results  are  often  ambiguous  and  different  people 
can  design  the  same  product  differently  and  different  people  can  read  UML  products 
differently.  For  UML  to  give  a  clear  view  of  a  problem  to  everyone  involved  in  the 
development  process,  it  must  be  used  in  combination  with  customer  and  team  reviews. 

CAMPEX  uses  a  "Two  Tier  Architecture"  through  the  choice  of  ACCESS  2000 
for  the  prototype  implementation.  A  "Three  Tier"  object-oriented  design  could  provide 
added  benefits  only  under  special  circumstances.  The  designer  must  keep  in  his  mind  that 
one  can  validate  fully  the  Requirements  Specification,  use  the  same  GUI  design  for  the 
final  application  and  verify  the  correctness  of  objects,  but  one  can  only  partially  validate 
the  design  of  object  interactions. 

Keeping  the  prototype's  Database  and  GUI  and  implementing  the  computations 
with  a  classic  object-oriented  programming  language  will  complete  the  CAMPEX 
Employment  Module  implementation.  CAMPEX  will  be  the  basis  for  implementation  of 
other  Air  War  College  planning  modules.  Parts  of  CAMPEX  will  be  components  of  other 
modules,  and  CAMPEX  itself  will  be  a  component  in  a  distributed  environment  where 
students  exercise  air  campaign  plans. 


APPENDIX  A  -  USE  CASES 


USE  CASE  (Ul):  START  EMPLOYMENT  MODULE 


Actors: 

Purpose: 

Overview: 


Type: 

Cross  References: 


Student 

Select  to  start  the  CAMPEX  Employment  Module 

Student  Selects  to  use  the  CAMPEX  Employment  Module,  the 

program  displays  the  Introduction  Reports  and  "Ground  Forces 

Report."  Alternative  the  student  can  select  to  see  only  the  "Ground 

Forces  Report"  and  continue  with  the  program. 

Primary  and  essential 

R3.1,  R3.2,  R3.3,  R3.4,  R3.4,  R3.5,  R3.6,  R3.6,  R3.7,  R3.8,  R3.9, 

R3.10,  R3.ll,  R3.12,  R3.13,  R3.14,  R3.15,  R3.16,  R3.17,  R3.18, 

R3.19,  R3.20,  R3.21,  R3.22,  R10.1,  R10.1 1,  R10.12,  R10.13, 

R10.14 

Use  Cases:  - 


Section:  Main 
Typical  Course  Events 

Actor  Action 


1.         This  use  case  begins  when  student 


selects  to  load  the  CAMPEX 


Employment  Module. 


System  Response 


2         Displays  the  initial  screen  of 
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Selects  "Continue" 


The  student  chooses  an  option  to 

continue: 

To  see  Introduction  Reports,  go 
to  "Intro  Screen"  section 
To  continue  without  seeing  the 
"Introduction    Reports,"    go    to 
"Continue"  section 


Selects  to  Continue 


CAMPEX  Employment  Module 


Asks  student  if  he  wants  or  does  not 


want  to  see  the  Introduction  Reports. 


6.         Displays  Ground  Combat  Units  as  of 
Day  1  screen 

8.         Displays  the  ATO  Management 
screen 


Alternative  Courses:  - 
Section:  Intro  Screens 
Typical  Course  Events 

Actor  Action 


1 


Selects  to  see  "Intro  Screens" 


System  Response 
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4.         Selects  to  Continue 


6.         Selects  to  Continue 


8.         Selects  to  Continue 


10.       Selects  to  Continue 


12.       Selects  to  Continue 


14.       Selects  to  Continue 


16.       Selects  to  Continue 


18.       Selects  to  Continue 


2.  Gets  all  the  Introduction  Reports 

3.  Displays  "Read  me  file  for 
CAMPEX  Employment  Module" 

5.  Displays  the  "Execute  Order" 

7.  Displays  "DIA  Intel  Update" 

9.'  Displays  "Thai  Forces  Available" 

1 1 .  Displays  "Weather  Report " 

13.  Displays  "Navy  Update" 

15.      Displays  "Weapon  Availability 
Update" 

17.      Displays  "Program  Notes" 

19.      Displays  "Bomb  Damages 


Assessment  and  Target  Definitions" 


20.       Selects  to  Continue 
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21.       Displays  "Analysis  and  Corrections" 


Section:  Continue 


Typical  Course  Events:  No  additional  events 


USE  CASE  (U2):  STUDENT  INFO 


Actors: 

Purpose: 

Overview: 


Type: 

Cross  References: 


Student 

Student  identifies  himself 

Student  inserts  his  personal  information  in  the  CAMPEX.  If  he  has 

already  entered  his  personal  information  just  selects  his  own  name. 

Alternative  he  can  change  his  information. 

Primary  and  essential 

Rl.l,  R1.2,  R1.3,  R1.4,  R1.5,  R1.6,  R1.7,  R10.1 1,  R10.12, 

R10.13,R10.14 

Use  Cases:  "Start  Employment  Module"  Use  Case  (Ul) 


Section:  Main 


Typical  Course  Events 


Actor  Action 


1.       This  use  case  begins  when  student 


selects  to  identify  himself  to  execute 


an  exercise 


System  Response 


2.         Presents  available  "Student"  options 
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Chooses: 

Select  an  "Existing  User  Name," 

go     to     "Select    Existing     User" 

section. 

Enter  a  "New  User,"  go  to  "New 

User"  section. 

"Change  Student  Information,"  go 

to     "Change     User    Information" 

section. 


Section:  Select  Existing  User 
Typical  Course  Events 

Actor  Action 

1 .       This  use  case  begins  when  student 
selects  "Existing  User" 


3        Chooses  his  name 


4.         Presents  CAMPEX  Main  Menu 


screen 


System  Response 


2.        Presents  available  students'  names 


4.        Creates  the  selected  student 


instantiation 
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Section:  New  User 
Typical  Course  Events 

Actor  Action 

1.      This  use  case  begins  when  student 
selects  "New  User" 

3       The  student  enters  requested  personal 

information 
4.       Select  to  "Return" 


Section:  Change  User  Information 
Typical  Course  Events 

Actor  Action 

1 .       This  use  case  begins  when  student 
selects  "Update  User  Information" 


System  Response 


Presents  user  input  screen 


5.  Stores  student  entered  information 

6.  System  returns  student  to  previous 
GUI  from  where  student  can  follow 
the  process  of  section  "Existing 
Student" 


System  Response 


Presents  the  selected  user 


information 
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3        The  student  inputs  his  new 

information. 
4.       Select  to  "Return" 


5.  Stores  student  entered  information 

6.  System  returns  student  to  previous 
GUI  from  where  student  can  follow 
the  process  of  "Existing  Student" 
section. 


USE  CASE  (U3):  LOAD  AN  ATO 


Actors: 

Purpose: 

Overview: 

Type: 

Cross  References: 


Student 

Load  an  ATO 

Student  selects  an  ATO.  With  completion  student  is  entered  to 

"Main  Menu"  and  the  selected  ATO  is  loaded. 

primary  and  essential 

R4.1,R.4.2 

Use  Cases:  Student  must  have  completed  the 

•  "Start  Employ"  Use  Case  (U 1 ) 

•  Student  must  already  entered  the  ATO  that  wants  to 
load 


Section:  Main 
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Typical  Course  Events 

Actor  Action 

1 .  This  use  case  starts  when  the  student 
selects  to  "Load  an  ATO" 

2.  Selects  an  existing  ATO  from  the 
list. 


Select  to  continue 


System  Response 


3.  Creates  and  updates  the  necessary 
objects  of  the  selected  ATO 

4.  Displays  the  "Main  Menu"  screen  of 
ATO  Employment  Module 


USE  CASE  (U4):  MANAGE  AN  ATO 


Actors: 

Purpose: 

Overview: 


Type: 

Cross  References: 


Student 

Mange  an  ATO 

Student  selects  to  manage  to  an  ATO.  With  completion  selected  or 

new    ATO    information    should    be    in    CAMPEX    Employment 

Module. 

primary  and  essential 

R4.1,R4.3,R4.4,  R4.5,  R4.6 

Use  Cases:  Student  must  have  completed  the 
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"Start  Employment  Module  "  Use  Case  (Ul) 
"Student  Info"  Use  Case  (U2) 


Section:  Main 
Typical  Course  Events 

Actor  Action 

1.  Chooses     one     of     the     "ATO     1 
Management"     options.     Student 
selects 

"Start  a  new  ATO  from 
scratch,"  go  to  "Start  new  ATO 
from  scratch"  section. 
"Erase  an  existing  ATO,"  go  to 
"Erase  an  ATO"  section. 
"Copy  an  ATO  to  a  new  file, 
load  new,"  go  to  "Copy  an 
ATO"  section. 

2.  Continue  with  program 


Section:  Start  a  new  ATO  from  scratch 


Typical  Course  Events 


System  Response 


Displays  the  ATO  Selection  screen 
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Actor  Action 


1 .         Selects  Start  a  new  ATO  from 


scratch 


3.         Input  the  new  ATO  information 


System  Response 


Asks  to  enter  the  new  ATO 


information 


4.         Stores  the  new  ATO  information 


Section:  Copy  an  ATO 
Typical  Course  Events 

Actor  Action 
1.         Selects  Copy  an  ATO 
2  Enters  the  new  ATO  name 

4.         Selects  an  existent  ATO 


System  Response 


3.        Creates  necessary  ATO  objects 

5.        Updates  the  entered  ATO  to  the 
selected  ATO  information. 


Section:  Erase  an  ATO 
Typical  Course  Events 
Actor  Action 


1. 


Selects  Erase  an  existent  ATO 


System  Response 
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Selects  an  existent  ATO 


Deletes  selected  ATO  File 


information 


4.         Displays  the  "ATO  Selection"  screen 


USE  CASE  (U5):  DESCRIBE  THE  20  TARGETS  WITH  HIGHEST  PRIORITY 


Actors: 

Purpose: 

Overview: 


Type: 

Cross  References: 


Student 

Fill  the  list  with  20  targets  with  highest  priority 

Student  has  decided  which  targets  of  his  plan  have  the  highest 

priority.  Student  edits  the  list  of  20  targets  with  highest  priority. 

After  the  completion  of  this  use  case  the  student's  "20  Highest 

Priority  Target  List"  can  be  displayed  by  the  application. 

Primary  and  essential 

R5.1,  R5.2,  R5.3,  R5.4,  R10.2,  R10.1 1,  R10.12,  R10.13,  R10.14 

Use  Cases:  Student  must  have  completed: 

•  "Stan  Employment  Module"  Use  Case  (Ul) 

•  "Student  Info"  Use  Case  (U2) 

•  "Load  an  ATO"  Use  Case  (U3) 


Section  Main 
Typical  Course  Events 
Actor  Action 


System  Response 
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1.  This  use  case  begins  when  student  has 
already  decided  about  the  20  targets 
with  the  highest  priority 

2.  Student  selects  "Top  20  Targets" 


3.      Displays  the  current  list  of  top  20 


targets 


5.      Displays  all  targets 


4.       Student  chooses  a  Priority  List  place 


6.       Student  select  one  of  the  displayed 
targets 

7.      Updates  targets  priority 

If  the  target  is  already  in  the  list  then  the  program  doesn't  accept  the  selection  and 
displays  message  to  the  student  to  select  another  Target. 

USE  CASE  (U6):  PLAN  AN  ATO 


Actors: 

Purpose: 

Overview: 


Type: 

Cross  References: 


Student 

Enters  student's  plans 

Student  enters  new  missions,  or  edits  old  missions,  or  erases 

missions.  With  completion  of  this  Use  Case  the  student's  plans 

have  been  entered. 

Primary  and  essential 

R5.5,  R5.6,  R5.7,  R5.8,  R5.9,  R5.10,  R10.2,  R10.1 1,  R10.12, 
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R10.13,  R10.14 

Use  Cases:  Student  must  have  completed: 

•  "Stan  Employment  Module"  Use  Case  (Ul) 

•  "Student  Info"  Use  Case  (U2) 

•  "Load  an  ATO"  Use  Case  (U3) 


Section:  Main 
Typical  Course  Events 

Actor  Action 

1.  This  use  case  begins  when  student  is 
ready  to  enter  his  plan  in  the 
application 

2.  Student  selects: 

"Plan  an  ATO,"  go  to  "Plan  Edit 

Mission"  section 

"Cancel  a  Mission  or  a  Package  of 

Missions,"  go  to  "Cancel  a 

Mission  or  a  Mission  Package" 

section 


System  Response 


3.  Return  to  Main  Menu  screen 

4.  Displays  list  of  missions  or  packages 
of  the  selected  by  student  type 


131 


Section:  Plan  or  Edit  a  Mission 


Typical  Course  Events 


Actor  Action 


1 .       Student  select  to  Plan  or  Edit  a 


Mission 


3.       Chooses  one  option 


Selects  to  Enter  or  Edit  Mission 


7.       Student  enters  or  selects  a  mission 


9.       Enters  the  mission's  information 


10.     Exits  from  the  form 


System  Response 


2.        Displays  the  available  options  that 
user  can  see  the  lists  of  existent 
Missions. 

4.         Displays  list  of  missions  of  the 
student's  selected  type 

6.        Asks  from  the  student  to  enter  a  new 
mission  number  or  to  select  a 
mission  from  the  list  to  edit 

8.        Displays  an  input  form  for  the 
entered  or  selected  mission 


1 1.       Enters  new  mission  information  to 
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the  system 


Section:  Cancel  a  Mission  or  a  Missions' Package 
Typical  Course  Events 

Actor  Action 

1.  Student  selects  to  Cancel  a  new 
Mission  or  a  Mission 's  Package 

2.  Selects  an  existent  mission  or 


package  to  cancel 


USE  CASE  (U7):  FLY  AN  ATO 


System  Response 


3.      Deletes  selected  mission  or  package 
of  missions 


Actors: 

Purpose: 

Overview: 


Type: 

Cross  References: 


Student 

To  execute  the  planned  missions 

Student  is  running  fly  missions.  System  calculates  the  result  of  the 

planned  missions.  Saves  the  results  in  a  new  ATO.  Loads  the  new 

ATO. 

Primary  and  essential 

R6.1,  R6.2,  R6.3,  R6.4,  R6.5,  R10.2,  R10.1 1,  R10.12,  R10.13, 

R10.14 

Use  Cases:  Student  must  have  completed: 
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•  "Start  Employment  Module"  Use  case  (Ul) 

•  "Student  Info"  Use  Case  (U2) 

•  "Load  an  ATO"  Use  Case  (U3) 

•  "Plan  an  ATO"  Use  Cases  (optional)  Use  Case  (6) 


Section:  Main 
Typical  Course  Events 

Actor  Action 

1.  This  use  case  begins  when  student  has 
finished  his  plan  editing 

2.  Student  selects  "Fly  ATO" 


4. 


USE  CASE  (U8):  INITIAL  INFORMATION 


System  Response 


Calculates  the  results  of  the  planned 


missions 


Creates  a  new  ATO 


Saves  the  results  of  the  calculation  to 


the  new  ATO 


Loads  the  new  ATO 


Actors: 

Purpose: 

Overview: 


Student 

Inform  student  for  the  initial  data  of  an  ATO 

Student  asks  for  initial  information.  With  completion  of  this  Use 
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Type: 

Cross  References: 


Case  the  student  has  seen  or  printed  the  information  that  he  has 

asked  for. 

Primary  and  essential 

R7.1,  R7.2,  R7.3,  R7.4,  R7.5,  R7.6,  R7.7,  R7.8,  R7.9,  R7.10, 

R10.2,  R10.1 1,  R10.12,  R10.13,  R10.14 

Use  Cases:  Student  must  have  completed: 

•  "Start  Employment  Module"  Use  Case  (U 1 ) 

•  "Student  Info"  Use  Case  (U2) 

•  "Load  an  ATO"  Use  Case  (U3) 


Section:  Main 
Typical  Course  Events 

Actor  Action 

1 .  This  use  case  begins  when  student  has 
loaded  an  ATO  or  in  any  moment  of 
the  program 

2.  Chooses  to  see  actual  data  by: 

"Flights  without  Sorties" 

"Daily  Summaries" 

"Logistic  Requirements" 

"Blue  Basing  Summary  as  of  Start 

of  Current  Day" 

"Sorties    Available    to    Task    at 


System  Response 
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Airbases' 


'Analysis" 


"Recce   for  Targets   at   Stan   of 


Current  Date" 


5.       Chooses  one  option: 

print  report,  go  to  "Print  Report" 


section 


exit 


Section:  Print  Report 
Typical  Course  Events 

Actor  Action 
1.       Selects  "Print". 


3. 

4. 


Calculates  data  to  create  the  report 
Displays  the  selected  report 


Displays  the  Main  Menu  screen 
Displays  Main  Menu  screen 


System  Response 


Prints  the  displayed  report 


USE  CASE  (U9):  ESTIMATED  RESULTS 


Actors: 


Purpose: 


Overview: 


Student 


Display  the  estimated  results  by  the  student  plan  before  these  plans 


execute 


Student  asks  for  the  estimated  results.  With  completion  of  this  Use 
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Type: 

Cross  References: 


Section:  Main 


Case  estimated  results  are  displayed  on  the  screen. 
Primary  and  essential 

R8.1,  R8.2,  R8.3,  R8.4,  R8.5,  R8.6,  R8.7,  R8.8,  R8.9,  R8.10, 
R8.ll,  R8.12,  R8.13,  R10.2,  R10.ll,  R10.12,  R10.13,  R10.14 
Use  Cases:  Student  must  have  completed: 

•  "Start  Employment  Module"  Use  Case  (Ul) 

•  "Student  Info"  Use  Case  (U2) 

•  "Load  an  ATO"  Use  Case  (U3) 

•  "Plan  an  ATO"  Use  Cases  (Optional)  (U6) 


Typical  Course  Events 


Actor  Action 

1 .  This  use  case  begins  when  student  has 
finished  (editing)  his  plan  editing 

2.  Student  selects  "Estimated  Results" 


System  Response 


4.       Chooses  one  option 

6.       Chooses  available  options 
Selects  "Return" 
Selects  "Print",  go  to  the  "Print" 


3.        Displays  the  available  reports  that 
user  can  see  the  estimated  results 

5.        Displays  report  of  estimated  results 
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section 


Section:  Print 
Typical  Course  Events 

Actor  Action 

1.       Selects  "Print" 


10.       Displays  Main  Menu  screen 


USE  CASE  (U10):  ACTUAL  RESULTS 


System  Response 


Prints  the  displayed  report 


Actors: 

Purpose: 

Overview: 


Type: 

Cross  References: 


Student 

Inform  Student  for  the  Results  Reports  of  an  ATO 

Student  asks  for  Information.  With  completion  of  this  Use  Case, 

the  student  has  seen  or  printed  the  information  that  he  has  asked 

for. 

primary  and  essential 

R9,  R9.1,  R9.2,  R9.3,  R9.4,  R9.5,  R9.6,  R9.7,  R9.10,  R9.1 1, 

R9.12,  R9.13,  R9.14,  R9.15,  R9.16,  R9.17,  R9.18,  R9.19,  R9.20, 

R9.21,  R9.22,  R9.23,  R9.24,  R9.25,  R9.26,  R9.27,  R10.2,  R10.1 1, 

R10.12,  R10.13,R10.14 

Use  Cases:  Student  must  have  completed: 

•  "Start  Employment  Module"  Use  Case  (Ul) 

•  "Student  Info"  Use  Case  (U2) 


138 


"Load  an  ATO"  Use  Case  (U3) 


"Fly  an  ATO  Missions"  Use  Case  (U7) 


Section:  Main 
Typical  Course  Events 

Actor  Action 

1 .  This  use  case  begins  when  student  has 
flown  an  ATO  and  at  any  other 
moment  of  the  program  after  that 

2.  Chooses  to  see  actual  data  by: 

"Cumulative  Summary  During  the 
Previous  Date" 
"Current  Recce" 
"Enemy  Over  Blue  Bases" 
"Ground  War  Summary" 
"Measures  of  Merit" 
"Yesterday  Looses  by  Task  Type" 
"Yesterday    Looses    by    Aircraft 
Type" 
"Final  Target  Status" 


4. 


System  Response 


Calculates  data  to  create  the  report 
Displays  the  selected  report 


5.       Chooses  one  option: 
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print  report,  go  to  "Print  Report" 


section 


exit 


Section:  Print  the  Report 
Typical  Course  Events 

Actor  Action 
1.       Selects  "Print". 


USE  CASE  (Ull):  MAP 


6.        Displays  the  Main  Menu  screen 
10.       Displays  Main  Menu  screen 


System  Response 


Prints  the  displayed  report 


Actors: 

Purpose: 

Overview: 

Type: 

Cross  References: 


Section:  Main 


Student 

See  the  map  of  the  exercise  area 

Student  selects  to  see  the  map  by  Main  Menu.  With  completion 

map  is  displayed  on  the  screen 

Primary  and  essential 

R10.2,R10.3 

Use  Cases:  Student  must  have  completed: 

•  "Start  Employment  Module"  Use  Case  (U 1 ) 

•  "Load  an  ATO"  Use  Case  (U3) 


Typical  Course  Events 
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Actor  Action 

1 .       This  use  case  begins  when  student 
selects  from  "Main  Menu"  screen  to 
see  the  "Exercise  Map." 


USE  CASE  (U12):  SEND  EXERCISE 


System  Response 


Displays  the  Map  on  the  screen 


Actors: 

Purpose: 

Overview: 


Type: 

Cross  References: 


Section:  Main 


Student 

To  send  the  results  of  an  exercise  to  "Air  University" 

Student  must  be  connected  to  the  "internet"  first.  Then,  he  selects 

Option  of  CAMPEX  "Send  Exercise  Results  to  the  Air  University" 

and  selects  an  exercise  from  the  displayed.  With  the  completion  of 

this  use  case  the  selected  exercise  results  are  been  sent  to  the  Air 

University  server. 

Primary  and  essential 

R2.1,  R2.2,  R2.3,  R2.4,  RIO.  15 

Use  Cases:  User  must  have  completed  the 

•  "Student  Info"  Use  Case  (U2) 

•  User  must  have  connected  to  the  Internet 


Typical  Course  Events 

Actor  Action 

1.       This  use  case  begins  when  student 


System  Response 
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decides  to  send  the  result  of  his 
exercise  to  the  server  of  Air  War 
College 

2.  Connect  to  Internet 

3.  Selects  "Send  the  Result  to  the  Air 
War  College" 


4.  Collects  the  necessary  information 

5.  Sends  the  necessary  Information  to 


Air  College  Server 
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APPENDIX  B  -  SYSTEM  SEQUENCE  DIAGRAMS 


SELECT  STUDENT 


s:  Student 


:GUI 


Select  "Student  Services'!; ) 


select  Student(Name) 


:  Application 


s:initStudentServices  (JUL  Script 


s:=  selectStudent  (SSN):  Script 


GUI  maps  Studert 
names  to  SSN 


i 


st:=getStudent():  Student 


:Database 


SL-  getStudentSel(with  selection = 
Yes):  Student 


update  Student(st,No) 


st'=  getStudent(SSN): 
Student 


update  Student(st'?Yes) 


Repealed  for  ill     L 
Students | 


Figure  43.  Sequence  Diagram  "Select  a  Student' 
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ADD  STUDENT 


r,  Student 


:GUI 


Select  "Stadett  Services'^ ) 


Irput  Scident(SSN^nl(, 
fiistHamie ,  kstN^me ,  coundiy , 
ddress,e-Mdl,  section) 


implication 


s:initMentSen/ices  0UI:Scqjt 


ddStudent(SSNjfflk, 
fiistName,lastName, 
ccnmtiy,  address,  e-Mail, 

section) 


UserertersStudail^ 
Infomatifln 


Figure  44.  Sequence  Diagram  "Add  Student" 
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START  EMPLOY 


s:  Student 


:GUI 


Seto"Ccintiraiewih 
Introduction  Reports'!; ) 


Select  "Continue  wih  Ground 


implication 


report:=gettoroRepciits(): 
Scqrt. 


s:=  getRepart^'  Ground 
Ms'):  Sa?)t 


database 


ir  :=  getintroReport( ):  Repent 


gu  :=  getGroundlM( ):  GroundM 


r  :=  ae«LeRepoit(  "Ground  Ms'): 
Report 


updaleReport(r,gu):  Report 


to  impy,  baw  Crwmd   ^^ 
"It  jiyiLiiif  lichk"  mil* 


Repeatedfbr&ll  I 
Ittroduilm  Repeats 


Repetedfbrall  ^ 
Grouodttas      • | 


Figure  45.  Sequence  Diagram  "Start  an  ATO" 
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SELECT  ATO 

s:  Student 

:GUI 

implication 

database 

Select" 

Change  AT  O'O 

Select  an  AT  0  (description,day) 

5  :=initSelectATO  GUI:  Script 

st:=  getStndent(«lectic(n=Yes ):  Student 
—       fc 

V 

a:=getAT0(st):AT0 

fcjtitdfciiMIO  k 

s:=loadATODay(SSN, 
description,  day):  Script 

¥ 

ad:=  getAT0Day(a):AT0 

• 

W 

adl:=getATODaySel(wih 
sekctian.  =yes) :  ATODay 

r 

P 
updnt*AT0Diy(4dl,No) 

V 

st:=getStudent(SSN):  Student 

i:=  getATO  (st,  description) :  ATO 

ad2:=  getATODay  (a,  day) :  ATODay 

updateATODay(ad2,Yes) 

w 

ad3:=getATODay(a,withday> 
ad2.day)  ATODay 

Kepeaiedforall   ^ 
ATODay  biggerthn 
Elected  <fy  id  of  i. 

deleteMsn(ad3) 

w 
delete  Grcup(ad3) 

delete  Tgt(ad3) 

w 
delete  Sectoi(ad3) 

deleteATODay(ad3) 

p> 

Figure  46.  Sequence  Diagram  "Select  an  ATO" 
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NEW  ATO 


s:  Student 


:GUI 


Select  "Change  AT  O'O 


Select  "To  enter  a  New 
AT0"() 


Input  ATO  Information 
(description) 


:  Application 


s:=initSelect  ATO  GUI: Script 


addAT0(st,  description) 


:Database 


st:=  getStudent(selectiion=Yes ):  Student 


addATO  (st,  description) 


a:=getATO(st,  description)  :AT0 


addATODay(a,wihday=l) 


ad:=getAT  0Day(a,  with  day=  1) 
:AT0Dsy 


g:=get  Group  AllQ  :  Group 


addGroup(ad,g) 


s:=getSectorAUO :  Sector 


adidSector(ad^) 


t:=getT£A110  target 


addTgtfadJ) 


I.iJtltdfclillL'ItiriJ. 


l»J64»df(>I4l&<;t>I» 


Iij4ifc.l£i>I\JlIlI#t 


b 


Figure  47.  Sequence  Diagram  "New  ATO" 
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COPY  AN  EXISTING  ATO 


s:  Student 


:GUI 


"New  AT0"(descr5itianl) 


"Select  ATO  To  Copy" 
(descriptions) 


Select  "Change  AT  O'O 


Select  "To  copy  an  AT0'( ) 


:  Application 


s  :=miCopyAT  0  C-Ul:  Scrpt 


selectATOToCopy(SSN, 
description! ,  descnption2) :  Script 


Desaptknl  is  ira  |k 
newwddesa^tiorui 
for  existed  ATO. 


:Database 


st:=  getStudent(seleaion=Yes ):  Student 


al:=getAT0(st):AT0 


adl:=  getATODay(al):ATO 


st:=getStudent(SSN):  Student 


addATO(SSN,descnptionl)  ATO 


a:=getAT0(st4escriprionl):ATO 


a':=  getATO  (st, descriptions):  ATO 


ad';  =getATODay(a'):ATODay 


addATODay  (a,  ad'  day):ATODay 


ad:getATODay  (a,  ad'  day):ATODay 


g:=getQroup  (ad'):  Group 


addGroup  (g',ad):  Group 


t:=getTarget  (ad'):  Target 


addTarget  (t^d):  Target 


s:=getSector  (ad'):  Sector 


addSector  (ad,s) 


m.:getMission  (ad'):  Mission 


iddMissicn  (ad^ti) 


5j.I41t.lt>  I  ill 


•iu: 1 


lij*it'jbx  il  Group 
of  ad'  : 


ip*4tfo«l L 


of«A'    J J 


Iji^lT.jliHIiIi^'Is    L 

»f:»a'  i  | 


Figure  48.  Sequence  Diagram  "Copy  an  Existing  ATO" 
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ERASE  ATO 


s:  Student 


:GUI 


Select  "Delete  an  AT  O'H 


Select  an  ATO  to  EhseQ 


implication 


5 —nutCqpyAT  0  GULSaipt 


:Database 


stl:=  getStuclent(selecti0n=Yes ):  Stuck  t 


il:=  getATO(stl)ATO 


adl:=  getATQD*y(al)ATO 


st:=  getStudent  (SSN) :  Student 


4:=  getATO  (st,  destiption)  ATO 


ad:=getATODay(i,*liy) 


delete  Group  (id) 


delete  Tgt  (ad) 


delete  Sector  (id) 


deleteMsn  (ad) 


deleteATODay  (a,day) 


delete  ATO  (rtjdescrftion) 


Lsjiiidtoiil 
fruit  nmAIO 


kjsifcdfeidixiaiv  «f  »^i 


S-ilJtiSdtoljJlC'K^.  of d~\ 


I»j»ifi4fciJl  I  u*»  of  1A 


ljij*itiifoi.dl!4ctn  of  id  k. 


ijii*ibd  tfi-iUlIi .  i'  i»-  of  id  Iti 


Figure  49.  Sequence  Diagram  of  "Erase  an  ATO" 
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20  TARGETS  WITH  HIGHEST  PRIORITY 


Student 


:GUI 


Select  "20  Targets  with 

Highest  Priority'O 


Select  Target  Information 
(TgtName,Posirion) 


implication 


s  :=init20TgsHighest  Priority 
GUI:  Script 


modir/Tgt  (SSN,  description, 
dsy,tgtNbr,  priority) :  Script 


pil'IlJ,' 


\ 


database 


stl:=  getStudent($electian=Ye5  ):Stu<tet 


d:=getAT0(stl):AT0 


sdl  :=  getAT  QDayftl):  AT  ODay 


t:=  getTgtfadl):  Target 


42:=  getATO(stl,selection=Yes):ATO 


id2:=  getAT  0D4y(42^elecrion= Yes) 
:ATQD*y 


tl=  getTgH*d2jriority<>0):ATODty 


st:=getStudent(SSN):Student 


i:=getATO(st,  description):  ATO 


&d:=getATODay  (i,d4y):  ATODay 


up  date  Tgt  (d,  tgtNbrpriority):Target 


EjJ$H5i3I       W 

lupfr  ofMQIV       I 


Figure  50.  Sequence  Diagram  "20  Highest  Priority  Targets" 
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PLAN  ATO  ENTER  A  NEW  MISSION 


s:  Student 


:GUI 


Select  "Plant  Ed±  Missions'^  ) 


Input  Mission  Information 
(MsnNbr,  TaskType ,  AcftType 
Base,  Sector,  Tgt,TgLCategory 
TgtSubcategary,  Bomb  Type , 
NbrOfSorUes,  Package) 


LLiilP-a  v  ft*  -ill/ 
T-\x-sni< to it  an  optional 


:  Application 


s  :=JrutPlmEditMsri  GUI:  Scrfot 


enterMsn  (st,  a,  ad,msnNbr, 
task  Type,  adt  Type,  base, 
sector,  tgtNbr,tgtCaLNbr, 
tgtSubNbr,  bamTypeNbr, 
nbrOfSorties ,  package) 


id:=  getATODay(a,selection=Yes):ATO 


:  Database 


st:=  getSTwdent(selectic<n=Yes  ):Studenl 


a:=  getATO(st,selecUon=Yes):ATO 


m:=  getMsn(ad):Mission 


m  :=getMsn  (admsnNbr):  Mission 


exist:checkMsnftn):  Boolean 


[exist]  rupdate Msn  (task  Type , 
acft.  Type,  base,  sector,  tgtNbr, 
tgtCatNbr,  tgtSubNbr, 
bamTypeNbr,  nbxOfSarties , 
package) 


[Not  exist]  :addMsn(ad,  MsnNbr, 
Task  Type ,  Acft.  Type ,  Base , 
Sector,  TgL,  Tg.Categoiy, 
TgtSubcategary,  Bomb  Type, 
NbrOfSorties,  Package):Mission 


Figure  51.  Sequence  Diagram  "Plan  or  Edit  Mission" 
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CANCEL  MISSION 


s:  Strident 


:GUI 


:  Application 


:  Database 


Select  "Cancel  Mission  or 
P*ck*€<T  ) 


Select  "Mission to  Delete' 
CMsaxNbO 


famuli  re  "Plan.  Edit  Missions' 
GUI 


delete  luasr<SSN,  description, 
day,  MsnKbr):  Script 


stl:  =  getStiadeitl<s«l«ctioon.=  Ves  ):Snxdert 


*1  =  getATOCstl^ATO 


*dl   =  fftATOD«y(tl)ATO 


rn  =  getMsru'adl)  Missi 


st := get gpidera.es  SIT):  Student 


*:  =  getATO(st„  descnptian):  ATO 


%d:=getATOE>*y  (%„  day):  ATOD«y 


de  Let*  lulsri  C  *d ,  ma\Khr) 


d«oi*Jl*vTO 


Figure  52.  Sequence  Diagram  "Cancel  Mission" 


CANCEL  MISSIONS  OF  A  PACKAGE 


s:  Strident 


:GUI 


Select  "Cancel  Mission  or 


Select  "P«d(»ge  to  Delete" 


:  Application 


s:=irutDel*teP«cl<«geGUI:Scrsrt 


deletePidogefSSNydescripuan 
.day,  m-padoge ):  Scnpt 


:Database 


stl:=  grtStudent<selecuon=Y«s  )  Studer  t 


«.!:=  g«AT0(5tl):ATO 


«dl  -  getATODgytAl)  ATO 


p:=  getMsnPl<gI>dl):lnteger 


st:=get  Student  (S  SN):  Student 


t:=getATO(st,desa-ipUC(n):  ATO 


•d  =g«ATOD«y  O,  dty):  ATODay 


deleteMsn  I'  ad,mp^»g«) 


H»«»xv  "l  iJ  tit 
haw  flo«  p^kty 


of  grnfonf  tt ^H 


K*fft«mtd£>x«JL 

jl».iHH»fMODv 


Figure  53.  Sequence  Diagram  "Cancel  Package  of  Missions" 
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FLY  ATO 


s:  Student 


:GUI 


:  Application 


:  Database 


Select  "Fly  AT  O'O 


flyATO  ()  .Script 


X:=  getStndent{selectLon=Yes  ):  Student 


i:=  getATO(st,selection=Yes):ATO 


update  AT  ODay  (ad,  No) 


ad:=  getATODay(a,selecti]on=Yes):ATO 


deleteMsnBad(ad,wilh  nbrQtfSorties=0 
Or  TaskType=0  Or  Ac±Type=0    ) 


K, i  iE Bid  lli tit, i»  of  id 


5 


addATOday  (ad,  ad.day+1) 


ad' :=getATODay(a,  ad.day+1):  ATODay 


update  ATODay  (ad',  Yes) 


m:=getMsn(4d):  Miss  ion 


addMsrtfad'  f  m) 


g:— getgj.oup(ad  ):  Group 


addGroup  (ad' ,  g) 


s  :=getSectoi(ad  ):  Sector 


addSecLor  (ad',s) 


t:=getTg(ad):  Target 


addTgt(ad',t) 


m:=getMsn(ad):Mission 


l:=cakMsnlosses§n):in<t.  array 


up  date  Msn(ad ' ,  m ,  1) 


up  date  Group  (ad ',  m .  group ,  1) 


update  Sectjor(ad' ,  m. sector,  1) 


update  Target(ad' ,  mtgt,  1) 


For  « II  Me: 


»ns  of «d     ] 


Figure  54.  Sequence  Diagram  "Fly  an  ATO" 
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ESTIMATED  RESULTS 


s:  Strident 


:GUI 


Select  "Eaitzuajtil  Results"  0 


:  Application 


rep  :=EsTTm«tedResults  (  ) 

S1U4JL 


id  =  grtATOD*y<»,selectian=Yes)  ATO 


^ 


:  Database 


st:=  getStudent(selecti0n=Y«s  y.  Student 


*  =  g«tATOCrt.,selectian=Ye$):ATO 


r:=createRepaxt  (ad/'Estiiiitted 
Results'^   Report 


tn : = getMsn(»d):  Mis  s  ion 


er : = c  al  dilate  Estimate  dRe  suits  £n) : 
Int. array 


ijpdaLrF>partJ  r.rti,  er  i 


Sfe*ag  of  *a 


Figure  55.  Sequence  Diagram  "Estimated  Results' 


MISSIONS  WITHOUT  SORTIES 


s:  Student 


:GUI 


Select  "Fbgts  Wahmi 
Sorties"  Q 


:  Application 


rep  := flights  WahoutSarties  (  ) 


id:=  getATOD*><i,selecUan=Yes):AT0 


:Database 


st:=  getStndentXselection=Yes  ):  Student 


i:=  getATO(st,selection=Yes)  ATO 


r:=cresteR*part(ad,  "Flints 
Without  Sorties"):  Report 


m:=  getMsn^&djWlri  sarties=0): 
Mission 


update  Reporter,  m) 


«tod£>xtlL  \ 

l'  1*  ■  ■  t  vi  TJUL  1 1     ™ 


Figure  56.  Sequence  Diagram  "Flights  Without  Sorties" 
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INITIAL  INFORMATION  -  DAILY  SUMMARY 


s:  Student 


:GUI 


Select  "Daily  Simrnary"  Q 


:  Application 


rep  :=daitySnmm*iy  0:Script 


sd:=  getATOD»y(i,selectian=Yes)AT0 


:Database 


jt:=  getStuderit(selecti0n=Yes  ):  Student 


a:=  getATO(st,selection=Yes):ATO 


r:=cre  atjeRepait(ad,  "Daily  Summary" 
):   Repeat 


m:=  getMsn(ad):  Mission 


update  Repeater,  m) 


l&MvXU  of  *d 


Figure  57.  Sequence  Diagram  "Daily  Summary" 


INITIAL  INFORMATION  -  LOGISTICS  REQUIREMENTS 


s:  Student 


Select  "Logistics 
Requirements"  Q 


:GUI 


rep:=LogisticsR*quir*ments  (  ) 
ScijpL 


:  Application 


id:=  getATODayt;a,selection=Yes)ATO 


:Database 


st:=  getStudent{selectian=Yes  ):  Student 


a:=  getATO(st,selection=Yes):ATO 


r:=createR*poit(ad,  "Logistic 
Requirements"):  Report 


in:  =getMsn(ad):  Mission 


lr:=  calcLogReq(m):Int.aTTay 
up  date  Rep  otrt^r,  m,  lr) 


i"i*j<i-iti'it.'i-iii 

jfegw  of  aA 


Figure  58.  Sequence  Diagram  "Logistic  Requirements" 
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INITIAL  INFORMATION  -  BLUE  BASING  SUMMARY 


s:  Student 


Select  "Bile  Basing 
S\immaxy"0 


:GUI 


:AppIicatLon 


rep  :=blueB»singS\imO:  Script 


»d:=  getAT0D»5<4^electitm=Yes):AT0 


:Datahase 


5t:=  getStud«nt(selectian.=Yes  ):  Student 


&:=  getATO(st,selectian=Yes):ATO 


r:=aeauR*poit(ad,  "Blue  Basing" 
):  Report 


ZJ 


g:=getQrov5>(ad):  Group 


updateRepartfr,  g  ) 


^ 


OoyTq*  of  ^A 


Figure  59.  Sequence  Diagram  "Blue  Basing  Summary' 


INITIAL  INFORMATION  -  "RECCE  FOR  TARGETS' 


s:  Student 


:GUI 


Select  "Recce  tor  Targets  "Q 


rep:=recceTgt^  ):Script 


:  Application 


id:=  getATODay(a^el*ction=Yes):ATO 


:Database 


st:=  getStudem(selectian=Yes  ):  Student 


&:=  getATO(st,«lectian=Yes):ATO 


r:=aeatjeReport.(ad?  "Recce  Target 
of  Day"):  Report. 


t:=getTg(ad):  Target 


151  date  Rep  ort(r,  t) 


Figure  60.  Sequence  Diagram  "Recce  for  Targets' 
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INITIAL  INFORMATION  -  "ANALYSIS" 


s:  Student 


:GUI 


Select  "Analysis"  0 


rep:=anarysis(  ):Scnpt 


:  Application 


id:=  getATODay(a^eleaio(n=Yes):ATO 


:  Database 


st:=  gwStud>ril(selectian=Yes  ):  Student 


a-  getATO(st,selection=Yes):ATO 


r=cre  ate  Rep  art(ad,  "Analysis"): 
Report 


m:=  getMsn(ad).  Mission 


«na:=  calculateAnafysis(Jn):Ir>t  array 


updsLeReparttr.m,  ana) 


l&ic<ioi*  of  Ojd 


Figure  61.  Sequence  Diagram  "Analysis" 


INITIAL  INFORMATION  -  "SORTIES  AVAILABLE" 


s:  Student 


:GUI 


Select  "Sorties  Av»il«ble"0 


:  Application 


rep  :=sarues  Available  (  ):  Script 


id:=  getATODay<»,selecUan=Yes):AT0 


:  Database 


st:=  eetStudexit{selectian=Yes  ):  Student 


a-  getATO(st,selection=Yes):ATO 


r:=creaLeRepart(ad,  "Available 
Sorties"):  Report 


g:=  getQraup(ad):  Group 


as  :=calculste  SartiesAvailable  (m,g 
):Integer 


updateRepart(r,  g,  as) 


ML»t»a*  of  ajj | 


Figure  62.  Sequence  Diagram  "Sorties  Available" 
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ACTUAL  RESULTS  -  "CUMULATIVE  SUMMARY' 


Student 


:GM 


Select  "Sorties  EBect"0 


:  Application 


rep  :=  Cumulative  Sum(  ):Script 


a:=  getAT0(st,  selection  Yes):AT0 


id-  getATODsy(i^electijC(rL=Yes):ATC 


r:=createRepart(id,  "Cumulative 
Summary"):  Report 


m:getMsn(ad):  Mission 


csl  "calculate  Cum  SumPl(m):Int.airay 


:Database 


st  -  getStiiderit(selectiori=Yes ):  Student 


ad':=getATOday(a,wiih 
diy<=ad.day):ATOD«y 


updateReport(r,m,  csl):  Report 


g:=getGroup(ad'):  Group 


cs2:=calculateCum  SumP2(g):Im.array 


updateRepor^r,  g,  cs2 ) 


t:=getTg(ad'):  Target 


cs3:=calculateCum  SumP3£t):&it.array 


updateRepcirt(r,t,  cs3 ):  Report 


I-ifs-itiltoiAllM 

iILlftHkliiiis,' 


ODyik 


R;  JULj.rif  .it'll' 


R.j  iHi>i*-oj»  ct-li' 


frliMn* 


t  c  l  id'     k. 


Figure  63.  Sequence  Diagram  "Cumulative  Summary" 
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ACTUAL  RESULTS  -  "ENEMY  OVER  BLUE  BASES" 


s:  Student 


:GUI 


Select  "Unrmy  Over  Blue 
B*ses"Q 


:  Application 


rep:=enemyOverBliieBises(  ) 
:Sciipl 


ld:=  getATOD^(%^election=Yes):ATO 


:Datahase 


st:=  getStudent(selectian=Yes  ):Student 


%:=  getATO(st,selectian=Yes):ATO 


r:= create  Report  (ad,  "Ehmy  Over 
Blue  Bases"):  Report 


b  =getB»ses(ad)    Btst 


g:=getGroup(ad):  Group 


eobb—caljCulateEliemyOverBlueB 
ases(b  ,g):Integer 

update Repeater,  b ,  g,  eobb) 


|k*I**.fcdfei«JlBA<ft»  *f*l  ^| 


lAJ6*«^dfr.I*Il&Tic1}»    of  >.  ^| 


Figure  64.  Sequence  Diagram  "Enemy  over  Blue  Bases" 


ACTUAL  RESULTS  -  "GROUND  WAR  SUMMARY" 


s:  Student 


:GUI 


Select "  Ground  War 

SlimrrnTy"!*) 


:  Application 


rep:— gluund^y|^S'UIIJl2la^y(  ) 


>d:=  getATODay(a,selection=Yes):ATO 


:Database 


st:=  getStndent(selectLan=Yes  ):Student 


«.:=  getATO(«.,5el«cuan=Ye5):ATO 


r:=cre  ateRepart(ad,  "  Ground  War 
Summary"):  Report 


s  :=getSector(*d):  Sector 


m:=getMsn(ad)  Mission 


sl:=c«lc  Sectarian):  Integer 


updateReparUr,  si):  Repoit 


3 


£*{«ivb<ltc.x*Jl 
Miction*  jpf< 


Figure  65.  Sequence  Diagram  "Ground  War  Summary" 
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ACTUAL  RESULTS  -  "MEASURES  OF  MERIT" 


s:  Student 


:GUI 


Select  "Measures  of  Merit"0 


implication 


rep:=measuresOfMerit  ( ) :  Script 


id:=  getATODay(aJ£electioin=Yes):ATC 


:Database 


5t:=  getS&Ldent(seleaiQn=Yes  ):  Student 


l:=  getAT  0(st,  selection=yes):  AT  0 


r:=creatjeRepart(ad,  "Measures  of 
Merit"):  Report 


ad:=getAT  Oday(a,  with  day 
smaller  than  the  user  inpuLday): 
ATODay 


m:=getMsn(ad):  Mission 


ad'  :=getAT  Oday(a,  with  day  =ad. 
day+ land  smaller  than  the  user 
inputday):ATODay 


m':=getMsn(ad'):  Mission 


oi:=calculate  OverallMcator 
s(tn,m'):Inl.airay 


updateRepcnt(r,  oi,  m):  Report 


fcijtitdfn 


di 


ffi^g  oiii  1 


Figure  66.  Sequence  Diagram  "Measures  of  Merit" 
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ACTUAL  RESULTS  -  "YESTERDAY  LOSSES  BY  AIRCRAFT  TYPE" 


s:  Studeni 


:GUI 


Select  "Yesterday  Losses  By 
Aircni"0 


:  Application 


rep:=yesterdiyLossesByAcft  ( 
):Sa|t 


3 


:Database 


St.-  getStudert^selection=Yes ):  Student 


.:=  getATO(st,selection=Yes):ATO 


ad:=  getAT0(4^electicin=Yes):AT0 


r:=cre  «teReport(4d,  "Yesterday  Losses 
By  Aircrai  Type"):  Report 


4cft:getAciType:Aircnl 


m:=getMsr<id,with4ciType : 
ici):Missiori 


ad':=getATODay(a,with  diy=ad.day- 
1):  ATODay 


m' :=getMsn(id',  wihmsnHb  r= 
nunsriNbr)  :Mission 


los  :=cdail9leLo5ses0ii^n'):Inleger 

updateRepoit(r,  los,  m ):  Report 

3 


EflMnidt'iill^jicaft  I 


Figure  67.  Sequence  Diagram  "Yesterday  Losses  By  Aircraft  Type" 
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ACTUAL  RESULTS  -  "YESTERDAY  LOSSES  BY  TASK  TYPE" 


s:  Student 


:GUI 


Select  "Yesterday  Louts  By 
T«k  Type  "0 


:  Application 


rep  :=yesterd)yLossesByTasl< 
Type  ():Sa^t 


:Datahase 


st:=  getStudent(selection=Yes  ):  Student 


»:=  getATO(st,selection=Yes):ATO 


ad:=  getATO(a,selectian=Yes)  ATO 


r:=aneaLeR*poxt(ajd,  "Yesterday  Losses 
By  T«sk  Typ«" ):  Report 


Z3 


xsk  :getTasl<Type .  Task  Type 


m:=getMsn(ad,  win  task  Type  : 

tit.  "j:  Mission 


ad':=getAT0Day(i,W3lh  d*y=»d.day- 
1):  ATODty  


m  * : = getMsn(ad  * ,  vrAh  msnNb  i 
mnvntHbr)  Mission 


los  :=c»lculatjeLosses(>n^aa,):IntjegeT 
\ip  date  Reporter,  los,  m  ):  Report 


2 I 


Zl21 


Figure  68.  Sequence  Diagram  "Yesterday  Losses  By  Task  Type" 


MAP 


s:  Stmleiit 


:GUI 


:  Application 


:  Database 


Select  **Mj£>s"(  ) 


Select  "Are*  lAxp"(  ) 


s:=mil£electM*ps  £  ):  Script 


*      m  =  fTtM*f.!    J  Mif. 


map:=  selectluatpCmapNbr  ) 


map    -    grtJulapCmjtpHbr  )  :  Map 


Figure  69.  Sequence  Diagram  of  "Map" 

162 


SEND  ATO 


s:  Student 


:GUI 


"New  ATO"  (description!) 


"SelectATOToSend" 
(descr5>tion2) 


Select  "Qumge  AT  O'O 


Select  "To  send  at  ATO'O 


:  Application 


MMs  "Send  ATO  GUT' 


selectATOToSend(SSN, 
descriptiml,des<iiption2)  :  Script 


Descrioucrilis  fru^L 
ATO  name  in  War 
College  Seirer  and 
<lescrpticri2forsen 
ATO. 


st:=  getStudent(selectiQn=Yes ):  Student 


exist:check  Student(S  SN):Boole  at 


:  Server  Database 


d:=getAT0(st):AT0 


adl:=  getATODayfo):ATQ 


[exist]  :«ddStadent(SSN):  Student 


st:=getStudent(SSN):  Student 


4ddAT0(SSN,desa?itionl)  :AT0 


a:=getAT  0(st4escriptionl):AT  0 


»':=  getATO  (st,descripticin2):  ATO 


ad':  =getAT0D«y  (a'):AT0Day 


aJdATODay  (*.,  MJ'.day):ATODay 


4d:getAT0Dsy  (i,  ad'.d*y):ATODay 


g:=getGroup  (»d'):  Group 


addGroup  (g',ad):  Group 


t:=getTaget  (id'):  Taget 


addTaget  (t,ad):  Taget 


s:=getSectar(ad'):  Sector 


addSectar  (id,s) 


tn:getMission(ad'):  Mission 


iddMissian  (ad;n) 


GJm5Z£x*]I 

Sink  nttt  Aid 


ffstadert  exist 
continue  wilh  next 
step 


♦Hi I 


IdKllj  of  id' | 


*£   \ J 


Figure  70.  Sequence  Diagram  "Send  ATO" 
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APPENDIX  C  ABBREVIATIONS  ACRONYMS  DEFINITIONS 


Abbreviation 

Word 

Explanation 

Active  X 

Transition  from  OLE  of  Microsoft 

Adaptability 

The  ease  with  which  software  can  be  modified  to 
meet  new  requirement  [DODSTR  92,  p.47] 

Cohesion 

The  manner  and  degree  to  which  the  tasks 
performed  by  a  single  component  are  related  to  one 
another 

Coupling 

IThe  degree  of  data  or  control  connectivity 
between  different  assets  of  a  software  system. 
Because  coupled  assets  cannot  be  separated  from 
each  other  easily  and  used  alone,  the  scope  of  reuse 
is  narrowed. 

2.  The  manner  and  degree  of  interdependence 
between  components. 

DCE 

Distributed 
Computing 
Environment 

DCOM 

Distributed 
Component  Object 
Model 

4GL 

Four  Generation 
Languages 

Interoperability 

Measure  of  the  ability  to  share  information  between 
different  systems. 

NSDM 

National  Security 

OS 

Operating  System 

OLE 

Object  Linking 
and  Embedding 
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Abbreviation 

Word 

Explanation 

Reengineering 

The  process  of  examining  and  altering  an  existing 
software    component    in    order    to    reformat    or 
configure  it.   Reengineering  is  comprised  of  the 
subprocesses  of  reverse  engineering,  retargeting, 
restructuring,      redocumentation,      and      forward 
engineering. 

Stub 

COM  or  CORBA  Mechanism  that  allow  seamless 
access  to  remote  objects 

AI 

Air  Interdiction 

Air  operations  conducted  to  destroy,  neutralize,  or 
delay  the  enemy's  military  potential  before  it  can  be 
brought  to  bear  effectively  against  friendly  forces 
at  such  distance  from  friendly  forces  that  detailed 
integration  of  each  air  mission  with  the  fire  and 
movement  of  friendly  forces  is  not  required.  (Air 
War  College  Glossary.) 

ATO 

Air  Task  Order 

AWACS 

Airborne  Warning 
and  Control 
System 

BAI 

Battlefield  Air 
Interdiction 

BAI  was  a  subset  of  Air  Interdiction.  Missions, 
which  are  tasked  against  enemy  forces,  and/or 
resources  that  are  in  a  position  to  directly  influence 
and  affect  ongoing  land  operations,  but  which  are 
not  yet  directly  engaged  in  combat.  These  missions 
are  included  in  Interdiction  in  the  new  AFM  1-1 
and  BAI  no  longer  is  an  Air  Force  mission.  (Air 
War  College  Glossary.) 

BDA 

Battlefield 
Damage 
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Abbreviation 

Word 

Explanation 

Assessment 

CAS 

Close  Air  Support 

C3 

Command, 
Control,  and 
Communication 

DCA 

Defense 

Communications 

Agency 

DSA 

Defense 
Suppression  Area 

The  area  EF-1 1 1  or  Wild  Weasel  aircraft 
employing  stand-off  jamming  or  suppression  would 
be  responsible  for  negating  enemy  capability.  They 
would  not  penetrate  enemy  territory.  (Air  War 
College  Glossary.) 

EW 

Early  Warning 

FEBA 

Forward  Edge  of 
the  Battle  Area 

The  foremost  limits  of  a  series  of  areas  in  which 
ground  combat  units  are  deployed,  excluding  the 
areas  in  which  the  covering  or  screening  forces  are 
operating,  designated  to  coordinate  fire  support,  the 
positioning  of  forces,  or  the  maneuver  of  units.  (Air 
War  College  Glossary.) 

OCA 

Offensive 
Counterair 

Recce 

Reconnaissance 

SAM 

Surface  to  Air 
Missile 

SEAD 

Suppression  of 
Enemy  Air 
Defense 

Sortie 

In  air  operations,  an  operational  flight  by  one 
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Abbreviation 

Word 

Explanation 

aircraft.  (Air  War  College  Glossary.) 

UTC 

Unit  Type  Code 

A  five-character  alphanumeric  code  that  uniquely 
identifies  each  type  unit  of  the  Armed  Forces.  (Air 
War  College  Glossary.) 
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